【网络】Receive packet steering简称RPS
(2014-07-02 14:06:34) Linux 2.6.35于2010年8月1号发布,新增特性比较多,而其中最引我注意的为第一点:Transparent spreading of incoming network traffic load across CPUs。
关于此点改进的详细介绍可以查看LWN上的两篇文章:"Receive packet steering" and "Receive flow steering"。
下面我就自己的理解来做一下阐述,不当之处,多多包涵。J
首先是Receive Packet Steering (RPS)
随着单核CPU速度已经达到极限,CPU向多核方向发展,要持续提高网络处理带宽,传统的提升硬件设备、智能处理(如GSO、TSO、UFO)处理办法已不足够。如何充分利用多核优势来进行并行处理提高网络处理速度就是RPS解决的课题。
以一个具有8核CPU和一个NIC的,连接在网络中的主机来说,对于由该主机产生并通过NIC发送到网络中的数据,CPU核的并行性是自热而然的事情:
比如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表:
1.
2.
既然CPU核的分配由两个hash表值决定,那么就可以有一个算法来描述这个决定过程:
1.
2.
3.
a)
b)
算法的前两步比较好理解,而对于第三步可以用下面两个图来帮助理解。应用程序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核就到了上面算法的第三步。
分情况判断:
1.
2.