背景

工作中遇到客户反馈，上层应用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