背景
工作中遇到客户反馈,上层应用UDP固定间隔100ms发包,但本地tcpdump抓包存在波动,有的数据包之间间隔107ms甚至更多,以此重新梳理了下udp的发送流程。
udp发包流程
udp_sendmsg
UDP corking 是一项优化技术,允许内核将多次数据累积成单个数据报发送。在用户程序中有两种方法可以启用此选项:
使用 setsockopt 系统调用设置 socket 的 UDP_CORK 选项
程序调用 send,sendto 或 sendmsg 时,带 MSG_MORE 参数
如果没设置UDP_CORK,直接发送到ip层,根据客户只是偶尔出现时延过高的情况,可以确定UDP_CORK并没有被设置,udp这里应该是直接下发的,udp_send_skb之后直接到ip层,排除udp_sendmsg导致时延波动问题
int udp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
{
... ...
/* Lockless fast path for the non-corking case. */
if (!corkreq) {
struct inet_cork cork;
skb = ip_make_skb(sk, fl4, getfrag, msg, ulen,
sizeof(struct udphdr), &ipc, &rt,
&cork, msg->msg_flags);
err = PTR_ERR(skb);
if (!IS_ERR_OR_NULL(skb))
err = udp_send_skb(skb, fl4, &cork);
goto out;
}
... ...
}
qdisc发包流程
当配额quota < 0 || need_resched时将触发软中断,否则将直接进行发包。
quota 对应 net.core.dev_weight,可通过sysctl进行更改。
网卡及驱动
如果网卡慢,会导致网卡队列满返回BUSY,数据包重新入队,tcpdump将抓到重复的数据包。客户并未反馈该现象,排除网卡及网卡驱动。
总结
未配置UDP_CORK的情况下,上层udp应用send调用包含两个路径,一个是send直接到网卡驱动进行发送,另一个是send到网络设备子系统__dev_queue_skb,然后由软中断调用继续发送。
决定直接发还是由软中断发的条件是,net.core.dev_weight和 need_resched(需要强制调度),可以通过sysctl -a | grep weight查看其默认值。
对于__qdisc_run来讲,dev_weight代表循环次数,可尝试适当增大这个值,但可能会导致上层应用发送时延增加。
sysctl net.core.dev_weight=4096
need_resched则与中断\异常相关。
时延大的问题可能是软中断调度问题。
原文链接:https://www.cnblogs.com/forwards/p/17381458.html
本站文章如无特殊说明,均为本站原创,如若转载,请注明出处:UDP内核发包流程 - Python技术站