Linux的网络协议栈很独立，上下通过两个接口分别和用户态以及设备相连。也能够看作是北向和南向接口...北向通过socket接口，南向通过qdisc接口(你能够觉得是上层的netdev queue，对于接收接口，NAPI的poll队列则是还有一个样例)。无论是socket还是qdisc。都是基于队列来管理的，也就是说。三个部分是独立的。socket仅仅能看到读写队列。而看不到协议栈本身，socket在读一个数据的时候。它取的是队列里面的数据，至于说这个数据是谁放进去的，它并不知道。是不是协议栈放进去的，它也不必验证。
       socket隔离了用户进程和协议栈，RX/TX queue隔离了协议栈和设备驱动。
       这样的隔离方式给编程和设计带来了简便，然而却不利于性能。
       Linux的RPS设计，旨在让一个CPU既处理数据包的协议栈接收流程(软中断内核线程上下文，或者随意上下文的软中断处理)，又运行用户态处理该数据包的进程。

我说这样的设计有利也有弊。假设仅仅是旨在提高cache利用率，那么这样的设计是对的，可是有没有想过别的情况，假设一个CPU在NET RX软中断处理的最后将一个skb推到了一个socket队列。并试图唤醒等待进程，那么它下一步该干些什么呢？实际上它下一步应该返回设备。继续去poll下一个skb，然而RPS的设计不是这样。RPS的设计旨在希望让该CPU继续处理用户态进程....这就必定要进行一次进程切换以及用户/内核态的切换，尽管server的CPU cache利用率提高了，可是协议栈处理相关的CPU cache利用率反而减少了。其实，CPU cache是否在进程切换以及用户/内核态切换后刷新，这个是体系结构相关的，并非说全部的体系结构都能带来好的结果。
       必须做进一步的測试。
       我觉得最好的办法就是用户进程和内核的NET RX软中断处在不同的CPU核心上，然而这两个CPU核心共享二级cache或者三级cache。

...
       Linux内核随之发展出了更好的方案。那就是突破上述的独立三大部分，让socket直接深入到设备层直接poll skb！！

注意。这是一个poll操作，并非让socket直接处理协议栈流程。

socket直接poll的意思是说。socket在队列中没有读到数据包的时候，并非睡眠。然后等待NET RX内核线程将数据包放入队列后将其唤醒，而是直接去问设备：如今有数据包吗？假设有，我直接带走它们去协议栈，而不须要你送它们去了。这是一种“拉”的方式。而不是以往的那种“推”的方式。拉和推的差别在于。对于接收者，拉是同一个实体，是主动的，而推则是被动的。

这就攻克了RPS试图解决却又没有完美解决的问题。

这样的机制叫做busy poll。
       RPS试图让软中断处理完数据包后，切换到用户进程，此时软中断将间歇。然后数据包中断后又要切回来...busy poll就不是这样，它直接绕过了软中断这个运行体，直接靠socket自身所在的运行体来主动拉取数据包进行处理。

避免了大量的任务交接导致的切换问题。

我不晓得对于转发的情况，是否也能採用busy poll的方式来提高性能，这须要測试。以上的阐述仅仅是理想情况，真实情况是。socket可能替别的socket从设备拉取了一个数据包。甚至这个数据包仅仅是转发的，不与不论什么socket关联...由于数据包仅仅有经过标准的路由以及四层处理后，才干和一个详细socket关联。在设备驱动层。指望找到这个关联是徒劳且无望的！无论怎么说。控制权在用户自己手中，凭概率来讲，假设你的设备中大量的数据包都是转发包，就不要开启这个功能，假设你的进程拥有少量的socket处理大量的数据包，那就开启它，无论如何，这仅仅是一个使用方法和配置的问题，何时开启，以及份额设置多少，须要一个事前採样的过程。

今天早上起太早。写了两篇随笔。所以也就没出去溜，如今快七点了。小小和孩她妈还睡着呢，我准备下去上班了....