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处理大量的数据包，那就开启它，无论如何，这仅仅是一个使用方法和配置的问题，何时开启，以及份额设置多少，须要一个事前採样的过程。
今天早上起太早。写了两篇随笔。所以也就没出去溜，如今快七点了。小小和孩她妈还睡着呢，我准备下去上班了....