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继续处理用户态进程....这就必然要进行一次进程切换以及用户/内核态的切换，虽然服务器的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处理大量的数据包，那就开启它，不管怎样，这只是一个用法和配置的问题，何时开启，以及份额设置多少，需要一个事前采样的过程。