多核环境下的网卡中断处理

　　传统的单核环境中，没有太多的额外工作可以做，网卡收到数据后，驱动将中断直接给仅有的CPU就是了。

　　多核情形下，人们想到了以下的几个模型：

　　１．RR（轮转）：到达一个数据包，驱动将中断传给0号CPU，再到一个数据包，驱动又将中断传给1号CPU，以此类推。这种方式的一个极大的缺陷就是，容易导致包乱序。否决！

    ２．多队列、多中断号：网卡支持多个队列，每个队列又有一个独立的中断号。但网卡中的队列数往往是固定不变的，而这个数目如果与CPU个数相统一，那么就工作的很好，如果CPU个数跟它不一样呢？否决！

    ３．RPS(Receive Packet Steering)：驱动如果能够将中断分发到各个CPU，并且能保证每个流只用一个CPU来处理，这样就可以保证CPU的cache命中率，岂不是很好？没错，RPS就是为此而来的。RPS方案预想通过计算包中四元组的hash值来确定这个包要被分配到哪一个CPU上，因为这样可以基本保证分配的均等性和某个流被特定CPU所处理。但是如果计算hash值的任务如果由CPU来做，那么就涉及到CPU去读取报头，这将会导致cache miss，如果每个包都来一次cache miss，结局将是悲剧的。而事实上CPU必将miss，因为这个数据包是全新的、刚刚到达的。所以这个工作万万不能有CPU来做，那么谁来做呢？您也许想到了，是网卡本身。网卡产生了hash值后，由驱动去读取这个hash值，进而完成后续的中断分发。

　　以下内容来自http://page.renren.com/600235506/note/486210267

　　Linux 2.6.35于2010年8月1号发布，新增特性比较多，而其中最引我注意的为第一点：Transparent spreading of incoming network traffic load across CPUs。
　　关于此点改进的详细介绍可以查看LWN上的两篇文章："Receive packet steering" and "Receive flow steering"。
　　下面我就自己的理解来做一下阐述，不当之处，多多包涵。

首先是Receive Packet Steering (RPS)

　　随着单核CPU速度已经达到极限，CPU向多核方向发展，要持续提高网络处理带宽，传统的提升硬件设备、智能处理（如GSO、TSO、UFO）处理办法已不足够。如何充分利用多核势来进行并行处理提高网络处理速度就是RPS解决的课题。
　　以一个具有8核CPU和一个NIC的，连接在网络中的主机来说，对于由该主机产生并通过NIC发送到网络中的数据，CPU核的并行性是自热而然的事情：

　　问题主要在于当该主机通过NIC收到从网络发往本机的数据包时，应该将数据包分发给哪个CPU核来处理（有些具有多条接收队列和多重中断线路的NIC可以帮助数据包并行分发，这里考虑普通的NIC，普通的NIC通过RPS来模拟实现并行分发）：

　　普通的NIC来分发这些接收到的数据包到CPU核处理需要一定的知识智能以帮助提升性能，如果数据包被任意的分配给某个CPU核来处理就可能会导致所谓的“cacheline-pingpong”现象：
　　比如DATA0数据流的第一个包被分发给CPU0来处理，第二个包分发给CPU1处理，第三个包又分发给CPU0处理；而DATA1数据流恰好相反。这样的交替轮换（8核情况交替得更随意）会导致CPU核的CACHE利用过分抖动。

　　RPS就是消除这种CPU核随意性分配的智能知识，它通过数据包相关的信息（比如IP地址和端口号）来创建CPU核分配的hash表项，当一个数据包从NIC转到内核网络子系统时就从该hash表内获取其对应分配的CPU核（首次会创建表项）。这样做的目的很明显，它将具有相同相关信息（比如IP地址和端口号）的数据包都被分发给同一个CPU核来处理，避免了CPU的CACHE抖动现象，提高处理性能。
　　有两点细节：
　　第一，所有CPU核具有等同的被绑定几率，但管理员可以明确设置CPU核的绑定情况；
　　第二，hash表项的计算是由NIC进行的，不消耗CPU。

　　RPS的性能优化结果为大致可提升3倍左右。tg3驱动的NIC性能由90,000提升到285,000，而e1000驱动的NIC性能由90,000提升到292,000，其它驱动NIC也得到类似的测试结果。

接下来是Receive flow steering (RFS)

　　RFS是在RPS上的改进，从上面的介绍可以看到，通过RPS已经可以把同一流的数据包分发给同一个CPU核来处理了，但是有可能出现这样的情况，即给该数据流分发的CPU核和执行处理该数据流的应用程序的CPU核不是同一个：

　　不仅要把同一流的数据包分发给同一个CPU核来处理，还要分发给其‘被期望’的CPU核来处理就是RFS需要解决的问题。
　　RFS会创建两个与数据包相关信息（比如IP地址和端口号）的CPU核映射hash表：
　　１．一个用于表示期望处理具有该类相关信息数据包的CPU核映射，通过recvmsg()或sendmsg()等系统调用信息来创建该hash表（称之为期望CPU表）。比如运行于CPU0核上的某应用程序调用了recvmsg()从远程机器host1上获取数据，那么NIC对从host1上发过来的数据包的分发期望CPU核就是CPU0。
　　２． 一个用于表示最近处理过具有该类相关信息数据包的CPU核映射，称这种表为当前CPU表。该表的存在是因为有多线程的情况，比如运行在两个CPU核上的多线程程序（每个核运行一个线程）交替调用recvmsg()系统函数从同一个socket上获取远程机器host1上的数据会导致期望CPU表频繁更改。如果数据包的分发仅由期望CPU表决定则会导致数据包交替分发到这两个CPU核上，很明显，这不是我们想要的效果。

　　既然CPU核的分配由两个hash表值决定，那么就可以有一个算法来描述这个决定过程：
　　１．如果当前CPU表对应表项未设置或者当前CPU表对应表项映射的CPU核处于离线状态，那么使用期望CPU表对应表项映射的CPU核。
　　２．如果当前CPU表对应表项映射的CPU核和期望CPU表对应表项映射的CPU核为同一个，那么好办，就使用这一个核。
　　３．如果当前CPU表对应表项映射的CPU核和期望CPU表对应表项映射的CPU核不为同一个，那么：
　　　　a) 如果同一流的前一段数据包未处理完，那么必须使用当前CPU表对应表项映射的CPU核，以避免乱序。
　　　　b) 如果同一流的前一段数据包已经处理完，那么则可以使用期望CPU表对应表项映射的CPU核。

　　算法的前两步比较好理解，而对于第三步可以用下面两个图来帮助理解。应用程序APP0有两个线程THD0和THD1分别运行在CPU0核和CPU1核上，同时CPU1核上还运行有应用程序APP1。首先THD1调用recvmsg()获取远程数据（数据流称之为FLOW0），此时FLOW0的期望CPU核为CPU1，随着数据块FLOW0 : 0的到来并交给CPU1核处理，此时FLOW0的当前CPU核也为CPU1。如果此时THD0也在同一个socket上调用recvmsg()获取远程数据（数据流同样也是FLOW0），那么FLOW0的期望CPU核就改变为CPU0（当前CPU核仍然为CPU1）。与此同时，NIC收到数据块FLOW0 : 1，如何将该数据块分发给CPU核就到了上面算法的第三步。

　　分情况判断：

　　１．如果同一流的前一段数据包FLOW0 : 0未处理完，那么必须使用当前CPU核CPU1来处理新到达的数据块，以避免乱序。如下图所示（FLOW1流是应用程序APP1的）：

　　２．如果同一流的前一段数据包FLOW0 : 0已经处理完毕，那么可以使用期望CPU核CPU0来处理新到达的数据块。如下图所示（FLOW1流是应用程序APP1的）：

　　RFS适用于面向流的网络协议，它能更好的提升CPU的CACHE效率，不论是内核还是应用程序本身。RFS的性能优化结果在普通环境下为大致可提升3倍左右，而在多线程环境大致可提升2倍。能通过软件的形式提升机器网络带宽性能自然也是再好不过的事情了。