Linux内核UDP收包为什么效率低
现在很多人都在诟病linux内核协议栈收包效率低，不管他们是真的懂还是一点都不懂只是听别人说的，反正就是在一味地怼linux内核协议栈，他们的武器貌似只有dpdk。
但是，即便linux内核协议栈收包效率真的很低，这是为什么？有没有办法去尝试着优化？而不是动不动就dpdk。
我们从最开始说起。
linux内核作为一个通用操作系统内核，脱胎于unix那一套现代操作系统理论。
但一开始不知道怎么回事将网络协议栈的实现塞进了内核态，从此它就一直在内核态了。既然网络协议栈的处理在内核态进行，那么网络数据包必然是在内核态被处理的。无论如何，数据包要先进入内核态，这就涉及到了进入内核态的方式：
外部可以从两个方向进入内核-从用户态系统调用进入或者从硬件中断进入。也就是说，系统在任意时刻，必然处在两个上下文中的一个：
进程上下文中断上下文 (在非中断线程化的系统，也就是任意进程上下文)收包逻辑的协议栈处理显然是自网卡而上的，它显然是在中断上下文中，而数据包往用户进程的数据接收处理，显然是在应用程序的进程上下文中， 数据包通过socket在两个上下文中被转接。
在socket层的数据包转接处，必然存在着一个队列缓存，这是一个典型的 生产者-消费者 模型，中断上下文的终点作为生产者将数据包入队，而进程上下文作为消费者从队列消费数据包：
非常清爽的一个图，这个图是 两个上下文接力处理协议栈收包逻辑的必然结果 ，让我们加入一些实际必须要考虑的问题后，我们会发现这幅图并不是那么清爽，然后再回过头看如何来优化。
既然两个上下文都要在任意可能的时刻操作同一个socket进行数据包的转交，那么必须有一个同步机制保护socket元数据以及数据包skb本身。
由于linux内核中断，软中断可能处在任意进程上下文，唯一的同步方案几乎就是spinlock了，于是，真正的图示应该是下面的样子：
现在可以说，类似上面的这种这种保护是非常必要的，特别是对于tcp而言。
我们知道，tcp是基于事务的有状态传输协议，而且携带复杂的流控和拥塞控制机制，这些机制所依托的就是socket当前的一些状态数据，比如inflight，lost，retrans等等，这些状态数据在发包和接收ack/sack期间会不断变化，所以说：
在一个上下文完成一次事务传输之前，必须锁定socket状态数据。比方说发包流程。数据包的发送可以出现在两个上下文中：
进程上下文：系统调用触发的发包。中断上下文：ack/sack触发的发包。任何一个上下文的发包过程必须被tcp协议本身比如拥塞控制，流量控制这些所终止，而不能被中途切换到另一个上下文中，所以必须锁定。
问题是，上图中的锁定是不是太狠了些，中断上下文自旋时间完全取决于进程上下文的行文，这不利于软中断的快速返回，极大地降低了系统的响应度。
于是，需要把锁的粒度进行细分。linux内核并没有在横向上将锁的粒度做划分，而是在纵向上，采用两个层次的锁机制：
我们看到的linux内核在处理收包逻辑时的backlog，其实抽象出来就是上面的二级锁，它是不是很像windows的irql机制呢？伴随着apc，dpc，你可以把暂时由于高level的irql阻滞而无法执行的逻辑放入dpc：
由于进程上下文对socket的low锁占有，中断上下文将skb排入次level的backlog队列，当进程上下文释放low锁的时候，顺序执行次level被排入的任务，即处理backlog中的skb。
事实上这是一种非常常见且通用的设计，除了windows的irql，linux中断的上半部/下半部也是这种基于思想设计的。
前面说了，tcp的一次事务可能非常 复杂耗时 ，并且必须一次完成，这意味着期间必须持有socket low锁，以发包逻辑 tcp_write_xmit 函数为例，其内部循环发包，直到受到窗口限制而终止，每一次tcp_transmit_skb返回耗时3微秒～5微秒，平均4微秒，以每次发送4个包为例，在这期间，若使用spinlock，那么中断上下文的收包路径将自旋16微秒，16微秒对于spinlock而言有点久了，于是采用两级的lock机制，非常有效！
backlog队列机制有效降低了中断上下文的spin时延，提高了系统的响应度，非常不错。
但问题是，udp有必要这样吗？
首先，udp是无状态的，收包和发包都无需事务，协议栈对udp的处理，从来都是单个报文粒度的，因此只需要保护唯一的socket接收队列即可，即 sk_receive_queue 。
enqueue(skb, sk){ spin_lock(sk- >sk_receive_queue- >lock); skb_queue_tail(sk- >sk_receive_queue, skb); spin_unlock(sk- >sk_receive_queue- >lock);}sk_buff dequeue(sk){ spin_lock(sk- >sk_receive_queue- >lock); skb = skb_dequeue(sk- >sk_receive_queue); spin_unlock(sk- >sk_receive_queue- >lock); return skb;}需要保护的接收队列操作区间都是指令级别的时延，采用一把单一的 sk_receive_queue->lock 足矣。
确实，在linux 2.6.25版本内核之前，就是这么干的。而自从2.2版本内核，tcp就已经采用二级锁backlog队列了。
然而，在2.6.25版本内核中，linux协议栈的udp收包路径，转而采用了两层锁的backlog队列机制，和tcp一样的逻辑：
low_lock_lock(sk){ spin_lock(sk- >higher_level_spin_lock); // 热点！ sk- >low_lock_owned_by_process = 1; spin_unlock(sk- >higher_level_spin_lock);}low_lock_unlock(sk){ spin_lock(sk- >higher_level_spin_lock); sk- >low_lock_owned_by_process = 0; spin_unlock(sk- >higher_level_spin_lock);}udp_rcv(skb) // 中断上下文{ sk = lookup(...); spin_lock(sk- >higher_level_spin_lock); // 热点！ if (sk- >low_lock_owned_by_process) { enqueue_to_backlog(skb, sk); } else { enqueue(skb, sk);// 见上面的伪代码 update_statis(sk); wakeup_process(sk); } spin_unlock(sk- >higher_level_spin_lock);}udp_recv(sk, buff) // 进程上下文{ skb = dequeue(sk); // 见上面的伪代码 if (skb) { copy_skb_to_buff(skb, buff); low_lock_lock(sk); update_statis(sk); low_lock_unlock(sk); dequeue_backlog_to_receive_queue(sk); }}显然这非常没有必要。如果你有多个线程同时操作一个udp socket，将会直面这个热点，但事实上，你很难遭遇这样的场景，如果非要说一个，那么dns服务器可能首当其中。
之所以在2.6.25版本内核引入了二级锁backlog队列，大致是考虑到udp需要统计内存全局记账，以防udp吃尽系统内存，可以review一下 sk_rmem_schedule 函数的逻辑。而在2.6.25版本内核之前，udp的内存使用是不记账的，由于udp本身没有任何类似流控，拥塞控制之类的约束机制，很容易被恶意程序将系统内存吃尽。
因此，除了sk_receive_queue需要保护，内存记账逻辑也是需要保护的，比如累加当前skb对内存的占用到全局数据结构。但即便如此，把这些统计数据的更新都塞入到spinlock的保护区域，也还是要比两级lock要好。
在我看来，之所以引入二级锁backlog机制来保护内存记账逻辑，这是在 借鉴 tcp的代码，或者说 抄代码 更直接些。这个携带backlog队列机制的udp收包代码存在了好多年，一直在4.9内核才终结。
事实上，仅仅下面的逻辑就可以了：
enqueue(skb, sk){ spin_lock(sk- >sk_receive_queue- >lock); skb_queue_tail(sk- >sk_receive_queue, skb); update_statis(sk); spin_unlock(sk- >sk_receive_queue- >lock);}sk_buff dequeue(sk){ spin_lock(sk- >sk_receive_queue- >lock); skb = skb_dequeue(sk- >sk_receive_queue); update_statis(sk); spin_unlock(sk- >sk_receive_queue- >lock); return skb;}udp_rcv(skb) // 中断上下文{ sk = lookup(...); spin_lock(sk- >higher_level_spin_lock); enqueue(skb, sk);// 见上面的伪代码 spin_unlock(sk- >higher_level_spin_lock);}udp_recv(sk, buff) // 进程上下文{ skb = dequeue(sk); // 见上面的伪代码 if (skb) { copy_skb_to_buff(skb, buff); }}简单直接！linux内核的udp处理逻辑在4.10版本也确实去掉了两级的lock。恢复到了2.6.25内核版本之前的逻辑。
上面的优化带来了可观的性能收益，但是却并不值得炫耀。
因为上面的优化更像是解决了一个bug，这个bug是在2.6.25版本内核因为借鉴tcp的backlog实现而引入的，而事实上，udp并不需要这种花哨的backlog逻辑。所以说，上面的效果并非优化而带来的效果，而是解了一个bug带来的效果。
但是为什么迟至4.10版本才发现并解决这个问题的呢？
我想这件事可能跟quic有关。
用得少的逻辑自然就不容易发现问题，这就好比david miller在2.6版本内核引入ipv6实现的那几个bug，就是因为ipv6用的人少，所以一直在很晚的4.23+版本内核才被发现被解决。对于udp，一直到2.6.24版本其实现都挺好，符合逻辑，2.6.25引入的二级锁bug同样是因为udp本身用的少而没有被发现。
在quic之前，很少有那种有来有回的持续全双工udp长连接，基本都是request/response的oneshot类型的连接。然而quic却是类似tcp的全双工协议，在数据发送端持续发送大块数据的同时，伴随着的是接收大量的ack报文，这显然和tcp一样，也是一种反馈控制的方式来驱动数据的发送。
quic是有确认机制的，但是处理确认却不是在内核进行的，内核只是一个快速将确认包收到用户态quic处理进程的一个通路，这个通路越快越好！
也就是说，quic的ack报文的接收效率会影响其数据的发送效率。
随着quic的大规模部署，人们才开始逐渐关注其背后udp的收包效率问题。
摆脱了二级锁的backlog队列之后，仅仅是为udp后续的优化扫清了障碍，这才是真正刚刚开始。摆在udp的内核协议栈收包效率面前的，有一个现成的靶子，那就是dpdk。
挺烦dpdk的，说实话，被人天天说的东西都挺烦。不过你得先把内核协议栈的udp性能优化到接近dpdk，再把这种鄙视当后话来讲才更酷。
由于udp的处理非常简单，因此实现一个能和dpdk对接的udp用户态协议栈则并不是一件难事。而tcp则相反，它非常复杂，所以dpdk很少有完整处理tcp端到端逻辑的，大多数都只是做类似中间节点dpi这种事。目前都没有几个好用的基于dpdk的tcp实现，但是udp实现却很多。
dpdk的伪粉丝拿udp说事的，比拿tcp说事，成本要低很多。
好吧，那为什么dpdk处理udp收包效率那么高？
答案很简单， dpdk是在进程上下文轮询接收udp数据包的！也就是说，它摆脱了两个问题：
进程上下文和中断上下文操作共享数据的锁问题。进程上下文和中断上下文切换导致的cache miss问题。这两点其实也就是 “为什么内核协议栈性能干不过用户态协议栈” 的要点。当然，linux内核协议栈无法摆脱这两点问题，也就回答了本文的题目中的第一个问题， “linux内核udp收包为什么效率低？” 。
不同的上下文异步操作同一份数据，锁是必不可少的。关于锁的话题已经烂大街了。
现在仅就cache来讨论，中断上下文和进程上下文之间的切换，也有一个明显的case：
中断上下文中修改了socket的元统计数据，该修改会表现在cache中，然而当其wakeup该socket的处理进程后，切换到进程上下文的recv系统调用，其也或读或写这个统计数据，伴随着cache的flush以及cache的一致性同步。
如果这些操作统一在进程上下文中进行，cache的利用率将会高效很多。当然，回到udp收包不合理的backlog队列机制，其实backlog本身存在的目的之一，就是为了让进程上下文去处理，以提高cache的利用率，减少不必要的flush。然而，初衷未必能达到效果，在传输层用backlog将skb推给进程上下文去处理，已经太晚了，何必不再网卡就给进程上下文呢？就像dpdk那样。
其实linux内核社区早就意识到了这两点，早在3.11版本内核中引入的busy poll机制就是为了解决锁和切换问题的。busy poll的思想非常简单，那就是：
不再需要软中断上下文往接收队列里“推”数据包，而改成自己在进程上下文里主动从网卡上“拉”数据包。
落实到代码上，那就是在进程上下文的recvmsg函数中直接调用napi的收包函数，从ring buffer里拿数据，自己调用netif_receive_skb。
如果busy poll总能执行，它总是能拉取到自己下一个需要的数据包，那么这基本就是dpdk的效率了，然而和dpdk一样，这并不是一个统一的解决方案，轮询固然对于收包有收益，但中断是不能丢的，用cpu的自旋轮询换取收包效率，这买卖代价太大，毕竟linux内核并非专职收包的。
当然了，也许内核态实现协议栈本身就是一种错误，但这个话题有点跑偏，毕竟我们就是要优化内核协议栈的，而不是放弃它。
现在，我们不能指望busy poll担当所有的性能问题，仍然要依靠中断。既然依靠中断，锁的问题就是优化的重点。
以双核cpu为例，假设cpu0专职处理中断，而收包进程则绑定在cpu1上，我们很快能意识到， cpu0和cpu1对于每一个skb的enqueue和dequeue均在争抢socket的sk_receive_queue的spinlock 。
优化措施显而易见， 将多个skb聚集起来，一次性入接收队列 。显然，这需要两个队列：
维护聚集队列：由中断上下文将skb推入该队列。维护接收队列：进程上下文从该队列拉取skb。接收队列为空时，交换聚集队列和接收队列。
这样，同样在上述双核cpu的情况下，只有在上面的第3点的操作中，才需要锁保护。
考虑到机器的cpu并非双核，可能是任意核，收包进程也未必绑定任何cpu，因此上述每一个队列均需要一把锁保护，无论如何， 和单队列相比，双队列情况下，锁的竞争减少了一半！
collect_enqueue(skb, sk){ spin_lock(sk- >sk_collect_queue- >lock); skb_queue_tail(sk- >sk_collect_queue, skb); update_statis(sk); spin_unlock(sk- >sk_collect_queue- >lock);}sk_buff recv_dequeue(sk){ spin_lock(sk- >sk_receive_queue- >lock); skb = skb_dequeue(sk- >sk_receive_queue); update_statis(sk); spin_unlock(sk- >sk_receive_queue- >lock); return skb;}udp_rcv(skb) // 中断上下文{ sk = lookup(...); spin_lock(sk- >higher_level_spin_lock); collect_enqueue(skb, sk);// 仅仅往聚集队列里推入。 spin_unlock(sk- >higher_level_spin_lock);}udp_recv(sk, buff) // 进程上下文{ if (empty(sk- >sk_receive_queue)) { spin_lock(sk- >queues_lock); swap(sk- >sk_receive_queue, sk- >sk_collect_queue); spin_unlock(sk- >queues_lock) } skb = recv_dequeue(sk); // 仅仅从接收队列里拉取 if (skb) { copy_skb_to_buff(skb, buff); }}如此一来，双队列解除了中断上下文和进程上下文之间的锁竞争。
来看一下对比图示：
引入双队列后：
即便已经很不错了，但是：
中断上下文中不同cpu可能会收到同一个socket的skb，cpu依然会在聚集队列的锁上蹦跶。不同的cpu上的进程也可能会处理同一个socket，本意是合作，却需要接收队列的锁来将其操作串行化。没办法，通用的操作系统内核只能做到这里了，如果要解决以上的问题，就需要按照任何和角色明确绑cpu核心了，然而这也就不再是通用的内核了。最终，你会在内核里闻到dpdk的腐臭味，超级恶心。
对了，我暂且将双队列区分为了 聚集队列 和 接收队列 ，更好的名字可能是 backlog队列 和 接收队列 。中断上下文总是操作backlog队列，而进程上下文在接收队列为空时，交换backlog队列为接收队列。然而，backlog队列这个名字在我看来非常臭名昭著，所以，暂且不用它了。
…
我想本文应该就要结束了，确实没有源码分析，事实上，我觉得我写的这篇要比下面的这种有意思的多，然而可能在网上能找到的基本都是这种 非常详细的源码分析：
... bh_lock_sock(sk); // 锁定住sk if (!sock_owned_by_user(sk)) // 判断sk是不是被用户进程所拥有，如果没有被拥有的话。 rc = __udp_queue_rcv_skb(sk, skb); // 直接调用__udp_queue_rcv_skb else if (sk_add_backlog(sk, skb, sk- >sk_rcvbuf)) { //否则调用sk_add_backlog将skb放入backlog bh_unlock_sock(sk); // 如果失败，解锁sk，直接丢包 goto drop; } bh_unlock_sock(sk); // 解锁sk return rc; // 返回rc ...哈哈…
我为什么没有谈udp的gro，lro机制，因为太不通用了。但是另一方面，如果应用程序加以稍微支持，udp的gro，lro将会带来非常可观的收益，别忘了，内核只是udp报文的一个通路即可，既然是通路，它便不包含处理逻辑，越快通过，越好。如果你在乎高吞吐，那么就gro呗，如下：
udp的通用l4 gro相当于一个非常简单的5层协议，应用程序按照len字段稍加解析拆分即可，这将极大减少系统调用的次数，减少上下文切换带来的cache miss损耗。
怎样给笔记本加装固态硬盘
门头沟区与百度智能云签署战略合作协议
GGII:2021重点转向健康、智慧、UV等，LED照明“存量竞争”
如何使用代码控制开发板
计算机网络攻击方式中的被动攻击是什么
Linux内核UDP收包为什么效率低
苹果M1预示着RISC-V的崛起吗？
教你怎样用麻将牌制作能用的计算机，你说不定可以艳惊四座
can通信与uart通信的难度区别
梯云电梯物联网系统的实现原理
激光焊接技术在焊接内窥镜的应用
认真看待工业4.0，展望中国制造
2G逐渐退网，NB—IoT、5G将替代2G成为市场主流
用于EV充电系统栅极驱动的隔离式DC/DC转换器
AIoT行业飞速成长的赛道有哪些？
洗地机水管缺水提醒功能如何实现
高速气象监测站的功能特点及应用
ne555调光电路图大全（五款模拟电路设计原理图详解）
光缆室内布线选择应用
如何理解工控系统中的安全威胁
但是，即便linux内核协议栈收包效率真的很低，这是为什么？有没有办法去尝试着优化？而不是动不动就dpdk。
我们从最开始说起。
linux内核作为一个通用操作系统内核，脱胎于unix那一套现代操作系统理论。
但一开始不知道怎么回事将网络协议栈的实现塞进了内核态，从此它就一直在内核态了。既然网络协议栈的处理在内核态进行，那么网络数据包必然是在内核态被处理的。无论如何，数据包要先进入内核态，这就涉及到了进入内核态的方式：
外部可以从两个方向进入内核-从用户态系统调用进入或者从硬件中断进入。也就是说，系统在任意时刻，必然处在两个上下文中的一个：
进程上下文中断上下文 (在非中断线程化的系统，也就是任意进程上下文)收包逻辑的协议栈处理显然是自网卡而上的，它显然是在中断上下文中，而数据包往用户进程的数据接收处理，显然是在应用程序的进程上下文中， 数据包通过socket在两个上下文中被转接。
在socket层的数据包转接处，必然存在着一个队列缓存，这是一个典型的 生产者-消费者 模型，中断上下文的终点作为生产者将数据包入队，而进程上下文作为消费者从队列消费数据包：
非常清爽的一个图，这个图是 两个上下文接力处理协议栈收包逻辑的必然结果 ，让我们加入一些实际必须要考虑的问题后，我们会发现这幅图并不是那么清爽，然后再回过头看如何来优化。
既然两个上下文都要在任意可能的时刻操作同一个socket进行数据包的转交，那么必须有一个同步机制保护socket元数据以及数据包skb本身。
由于linux内核中断，软中断可能处在任意进程上下文，唯一的同步方案几乎就是spinlock了，于是，真正的图示应该是下面的样子：
现在可以说，类似上面的这种这种保护是非常必要的，特别是对于tcp而言。
我们知道，tcp是基于事务的有状态传输协议，而且携带复杂的流控和拥塞控制机制，这些机制所依托的就是socket当前的一些状态数据，比如inflight，lost，retrans等等，这些状态数据在发包和接收ack/sack期间会不断变化，所以说：
在一个上下文完成一次事务传输之前，必须锁定socket状态数据。比方说发包流程。数据包的发送可以出现在两个上下文中：
进程上下文：系统调用触发的发包。中断上下文：ack/sack触发的发包。任何一个上下文的发包过程必须被tcp协议本身比如拥塞控制，流量控制这些所终止，而不能被中途切换到另一个上下文中，所以必须锁定。
问题是，上图中的锁定是不是太狠了些，中断上下文自旋时间完全取决于进程上下文的行文，这不利于软中断的快速返回，极大地降低了系统的响应度。
于是，需要把锁的粒度进行细分。linux内核并没有在横向上将锁的粒度做划分，而是在纵向上，采用两个层次的锁机制：
我们看到的linux内核在处理收包逻辑时的backlog，其实抽象出来就是上面的二级锁，它是不是很像windows的irql机制呢？伴随着apc，dpc，你可以把暂时由于高level的irql阻滞而无法执行的逻辑放入dpc：
由于进程上下文对socket的low锁占有，中断上下文将skb排入次level的backlog队列，当进程上下文释放low锁的时候，顺序执行次level被排入的任务，即处理backlog中的skb。
事实上这是一种非常常见且通用的设计，除了windows的irql，linux中断的上半部/下半部也是这种基于思想设计的。
前面说了，tcp的一次事务可能非常 复杂耗时 ，并且必须一次完成，这意味着期间必须持有socket low锁，以发包逻辑 tcp_write_xmit 函数为例，其内部循环发包，直到受到窗口限制而终止，每一次tcp_transmit_skb返回耗时3微秒～5微秒，平均4微秒，以每次发送4个包为例，在这期间，若使用spinlock，那么中断上下文的收包路径将自旋16微秒，16微秒对于spinlock而言有点久了，于是采用两级的lock机制，非常有效！
backlog队列机制有效降低了中断上下文的spin时延，提高了系统的响应度，非常不错。
但问题是，udp有必要这样吗？
首先，udp是无状态的，收包和发包都无需事务，协议栈对udp的处理，从来都是单个报文粒度的，因此只需要保护唯一的socket接收队列即可，即 sk_receive_queue 。
enqueue(skb, sk){ spin_lock(sk- >sk_receive_queue- >lock); skb_queue_tail(sk- >sk_receive_queue, skb); spin_unlock(sk- >sk_receive_queue- >lock);}sk_buff dequeue(sk){ spin_lock(sk- >sk_receive_queue- >lock); skb = skb_dequeue(sk- >sk_receive_queue); spin_unlock(sk- >sk_receive_queue- >lock); return skb;}需要保护的接收队列操作区间都是指令级别的时延，采用一把单一的 sk_receive_queue->lock 足矣。
确实，在linux 2.6.25版本内核之前，就是这么干的。而自从2.2版本内核，tcp就已经采用二级锁backlog队列了。
然而，在2.6.25版本内核中，linux协议栈的udp收包路径，转而采用了两层锁的backlog队列机制，和tcp一样的逻辑：
low_lock_lock(sk){ spin_lock(sk- >higher_level_spin_lock); // 热点！ sk- >low_lock_owned_by_process = 1; spin_unlock(sk- >higher_level_spin_lock);}low_lock_unlock(sk){ spin_lock(sk- >higher_level_spin_lock); sk- >low_lock_owned_by_process = 0; spin_unlock(sk- >higher_level_spin_lock);}udp_rcv(skb) // 中断上下文{ sk = lookup(...); spin_lock(sk- >higher_level_spin_lock); // 热点！ if (sk- >low_lock_owned_by_process) { enqueue_to_backlog(skb, sk); } else { enqueue(skb, sk);// 见上面的伪代码 update_statis(sk); wakeup_process(sk); } spin_unlock(sk- >higher_level_spin_lock);}udp_recv(sk, buff) // 进程上下文{ skb = dequeue(sk); // 见上面的伪代码 if (skb) { copy_skb_to_buff(skb, buff); low_lock_lock(sk); update_statis(sk); low_lock_unlock(sk); dequeue_backlog_to_receive_queue(sk); }}显然这非常没有必要。如果你有多个线程同时操作一个udp socket，将会直面这个热点，但事实上，你很难遭遇这样的场景，如果非要说一个，那么dns服务器可能首当其中。
之所以在2.6.25版本内核引入了二级锁backlog队列，大致是考虑到udp需要统计内存全局记账，以防udp吃尽系统内存，可以review一下 sk_rmem_schedule 函数的逻辑。而在2.6.25版本内核之前，udp的内存使用是不记账的，由于udp本身没有任何类似流控，拥塞控制之类的约束机制，很容易被恶意程序将系统内存吃尽。
因此，除了sk_receive_queue需要保护，内存记账逻辑也是需要保护的，比如累加当前skb对内存的占用到全局数据结构。但即便如此，把这些统计数据的更新都塞入到spinlock的保护区域，也还是要比两级lock要好。
在我看来，之所以引入二级锁backlog机制来保护内存记账逻辑，这是在 借鉴 tcp的代码，或者说 抄代码 更直接些。这个携带backlog队列机制的udp收包代码存在了好多年，一直在4.9内核才终结。
事实上，仅仅下面的逻辑就可以了：
enqueue(skb, sk){ spin_lock(sk- >sk_receive_queue- >lock); skb_queue_tail(sk- >sk_receive_queue, skb); update_statis(sk); spin_unlock(sk- >sk_receive_queue- >lock);}sk_buff dequeue(sk){ spin_lock(sk- >sk_receive_queue- >lock); skb = skb_dequeue(sk- >sk_receive_queue); update_statis(sk); spin_unlock(sk- >sk_receive_queue- >lock); return skb;}udp_rcv(skb) // 中断上下文{ sk = lookup(...); spin_lock(sk- >higher_level_spin_lock); enqueue(skb, sk);// 见上面的伪代码 spin_unlock(sk- >higher_level_spin_lock);}udp_recv(sk, buff) // 进程上下文{ skb = dequeue(sk); // 见上面的伪代码 if (skb) { copy_skb_to_buff(skb, buff); }}简单直接！linux内核的udp处理逻辑在4.10版本也确实去掉了两级的lock。恢复到了2.6.25内核版本之前的逻辑。
上面的优化带来了可观的性能收益，但是却并不值得炫耀。
因为上面的优化更像是解决了一个bug，这个bug是在2.6.25版本内核因为借鉴tcp的backlog实现而引入的，而事实上，udp并不需要这种花哨的backlog逻辑。所以说，上面的效果并非优化而带来的效果，而是解了一个bug带来的效果。
但是为什么迟至4.10版本才发现并解决这个问题的呢？
我想这件事可能跟quic有关。
用得少的逻辑自然就不容易发现问题，这就好比david miller在2.6版本内核引入ipv6实现的那几个bug，就是因为ipv6用的人少，所以一直在很晚的4.23+版本内核才被发现被解决。对于udp，一直到2.6.24版本其实现都挺好，符合逻辑，2.6.25引入的二级锁bug同样是因为udp本身用的少而没有被发现。
在quic之前，很少有那种有来有回的持续全双工udp长连接，基本都是request/response的oneshot类型的连接。然而quic却是类似tcp的全双工协议，在数据发送端持续发送大块数据的同时，伴随着的是接收大量的ack报文，这显然和tcp一样，也是一种反馈控制的方式来驱动数据的发送。
quic是有确认机制的，但是处理确认却不是在内核进行的，内核只是一个快速将确认包收到用户态quic处理进程的一个通路，这个通路越快越好！
也就是说，quic的ack报文的接收效率会影响其数据的发送效率。
随着quic的大规模部署，人们才开始逐渐关注其背后udp的收包效率问题。
摆脱了二级锁的backlog队列之后，仅仅是为udp后续的优化扫清了障碍，这才是真正刚刚开始。摆在udp的内核协议栈收包效率面前的，有一个现成的靶子，那就是dpdk。
挺烦dpdk的，说实话，被人天天说的东西都挺烦。不过你得先把内核协议栈的udp性能优化到接近dpdk，再把这种鄙视当后话来讲才更酷。
由于udp的处理非常简单，因此实现一个能和dpdk对接的udp用户态协议栈则并不是一件难事。而tcp则相反，它非常复杂，所以dpdk很少有完整处理tcp端到端逻辑的，大多数都只是做类似中间节点dpi这种事。目前都没有几个好用的基于dpdk的tcp实现，但是udp实现却很多。
dpdk的伪粉丝拿udp说事的，比拿tcp说事，成本要低很多。
好吧，那为什么dpdk处理udp收包效率那么高？
答案很简单， dpdk是在进程上下文轮询接收udp数据包的！也就是说，它摆脱了两个问题：
进程上下文和中断上下文操作共享数据的锁问题。进程上下文和中断上下文切换导致的cache miss问题。这两点其实也就是 “为什么内核协议栈性能干不过用户态协议栈” 的要点。当然，linux内核协议栈无法摆脱这两点问题，也就回答了本文的题目中的第一个问题， “linux内核udp收包为什么效率低？” 。
不同的上下文异步操作同一份数据，锁是必不可少的。关于锁的话题已经烂大街了。
现在仅就cache来讨论，中断上下文和进程上下文之间的切换，也有一个明显的case：
中断上下文中修改了socket的元统计数据，该修改会表现在cache中，然而当其wakeup该socket的处理进程后，切换到进程上下文的recv系统调用，其也或读或写这个统计数据，伴随着cache的flush以及cache的一致性同步。
如果这些操作统一在进程上下文中进行，cache的利用率将会高效很多。当然，回到udp收包不合理的backlog队列机制，其实backlog本身存在的目的之一，就是为了让进程上下文去处理，以提高cache的利用率，减少不必要的flush。然而，初衷未必能达到效果，在传输层用backlog将skb推给进程上下文去处理，已经太晚了，何必不再网卡就给进程上下文呢？就像dpdk那样。
其实linux内核社区早就意识到了这两点，早在3.11版本内核中引入的busy poll机制就是为了解决锁和切换问题的。busy poll的思想非常简单，那就是：
不再需要软中断上下文往接收队列里“推”数据包，而改成自己在进程上下文里主动从网卡上“拉”数据包。
落实到代码上，那就是在进程上下文的recvmsg函数中直接调用napi的收包函数，从ring buffer里拿数据，自己调用netif_receive_skb。
如果busy poll总能执行，它总是能拉取到自己下一个需要的数据包，那么这基本就是dpdk的效率了，然而和dpdk一样，这并不是一个统一的解决方案，轮询固然对于收包有收益，但中断是不能丢的，用cpu的自旋轮询换取收包效率，这买卖代价太大，毕竟linux内核并非专职收包的。
当然了，也许内核态实现协议栈本身就是一种错误，但这个话题有点跑偏，毕竟我们就是要优化内核协议栈的，而不是放弃它。
现在，我们不能指望busy poll担当所有的性能问题，仍然要依靠中断。既然依靠中断，锁的问题就是优化的重点。
以双核cpu为例，假设cpu0专职处理中断，而收包进程则绑定在cpu1上，我们很快能意识到， cpu0和cpu1对于每一个skb的enqueue和dequeue均在争抢socket的sk_receive_queue的spinlock 。
优化措施显而易见， 将多个skb聚集起来，一次性入接收队列 。显然，这需要两个队列：
维护聚集队列：由中断上下文将skb推入该队列。维护接收队列：进程上下文从该队列拉取skb。接收队列为空时，交换聚集队列和接收队列。
这样，同样在上述双核cpu的情况下，只有在上面的第3点的操作中，才需要锁保护。
考虑到机器的cpu并非双核，可能是任意核，收包进程也未必绑定任何cpu，因此上述每一个队列均需要一把锁保护，无论如何， 和单队列相比，双队列情况下，锁的竞争减少了一半！
collect_enqueue(skb, sk){ spin_lock(sk- >sk_collect_queue- >lock); skb_queue_tail(sk- >sk_collect_queue, skb); update_statis(sk); spin_unlock(sk- >sk_collect_queue- >lock);}sk_buff recv_dequeue(sk){ spin_lock(sk- >sk_receive_queue- >lock); skb = skb_dequeue(sk- >sk_receive_queue); update_statis(sk); spin_unlock(sk- >sk_receive_queue- >lock); return skb;}udp_rcv(skb) // 中断上下文{ sk = lookup(...); spin_lock(sk- >higher_level_spin_lock); collect_enqueue(skb, sk);// 仅仅往聚集队列里推入。 spin_unlock(sk- >higher_level_spin_lock);}udp_recv(sk, buff) // 进程上下文{ if (empty(sk- >sk_receive_queue)) { spin_lock(sk- >queues_lock); swap(sk- >sk_receive_queue, sk- >sk_collect_queue); spin_unlock(sk- >queues_lock) } skb = recv_dequeue(sk); // 仅仅从接收队列里拉取 if (skb) { copy_skb_to_buff(skb, buff); }}如此一来，双队列解除了中断上下文和进程上下文之间的锁竞争。
来看一下对比图示：
引入双队列后：
即便已经很不错了，但是：
中断上下文中不同cpu可能会收到同一个socket的skb，cpu依然会在聚集队列的锁上蹦跶。不同的cpu上的进程也可能会处理同一个socket，本意是合作，却需要接收队列的锁来将其操作串行化。没办法，通用的操作系统内核只能做到这里了，如果要解决以上的问题，就需要按照任何和角色明确绑cpu核心了，然而这也就不再是通用的内核了。最终，你会在内核里闻到dpdk的腐臭味，超级恶心。
对了，我暂且将双队列区分为了 聚集队列 和 接收队列 ，更好的名字可能是 backlog队列 和 接收队列 。中断上下文总是操作backlog队列，而进程上下文在接收队列为空时，交换backlog队列为接收队列。然而，backlog队列这个名字在我看来非常臭名昭著，所以，暂且不用它了。
…
我想本文应该就要结束了，确实没有源码分析，事实上，我觉得我写的这篇要比下面的这种有意思的多，然而可能在网上能找到的基本都是这种 非常详细的源码分析：
... bh_lock_sock(sk); // 锁定住sk if (!sock_owned_by_user(sk)) // 判断sk是不是被用户进程所拥有，如果没有被拥有的话。 rc = __udp_queue_rcv_skb(sk, skb); // 直接调用__udp_queue_rcv_skb else if (sk_add_backlog(sk, skb, sk- >sk_rcvbuf)) { //否则调用sk_add_backlog将skb放入backlog bh_unlock_sock(sk); // 如果失败，解锁sk，直接丢包 goto drop; } bh_unlock_sock(sk); // 解锁sk return rc; // 返回rc ...哈哈…
我为什么没有谈udp的gro，lro机制，因为太不通用了。但是另一方面，如果应用程序加以稍微支持，udp的gro，lro将会带来非常可观的收益，别忘了，内核只是udp报文的一个通路即可，既然是通路，它便不包含处理逻辑，越快通过，越好。如果你在乎高吞吐，那么就gro呗，如下：
udp的通用l4 gro相当于一个非常简单的5层协议，应用程序按照len字段稍加解析拆分即可，这将极大减少系统调用的次数，减少上下文切换带来的cache miss损耗。
怎样给笔记本加装固态硬盘
门头沟区与百度智能云签署战略合作协议
GGII:2021重点转向健康、智慧、UV等，LED照明“存量竞争”
如何使用代码控制开发板
计算机网络攻击方式中的被动攻击是什么
Linux内核UDP收包为什么效率低
苹果M1预示着RISC-V的崛起吗？
教你怎样用麻将牌制作能用的计算机，你说不定可以艳惊四座
can通信与uart通信的难度区别
梯云电梯物联网系统的实现原理
激光焊接技术在焊接内窥镜的应用
认真看待工业4.0，展望中国制造
2G逐渐退网，NB—IoT、5G将替代2G成为市场主流
用于EV充电系统栅极驱动的隔离式DC/DC转换器
AIoT行业飞速成长的赛道有哪些？
洗地机水管缺水提醒功能如何实现
高速气象监测站的功能特点及应用
ne555调光电路图大全（五款模拟电路设计原理图详解）
光缆室内布线选择应用
如何理解工控系统中的安全威胁