在多核系统上网络数据转发实验和一点思考

ShadowStar

因为本地硬中断向本地CPU添加了poll_list，所以本地CPU上的软中断检测到了这个poll_list，所以后续的网络处理是在这个CPU上。

Godbach

好文啊。再加上九贱兄和ShadowStar兄的讨论，收获颇丰。

独孤九贱

原帖由 ShadowStar 于 2009-5-19 13:33 发表
因为本地硬中断向本地CPU添加了poll_list，所以本地CPU上的软中断检测到了这个poll_list，所以后续的网络处理是在这个CPU上。

哈哈，看来我们从原理到结论都取得了一致，现在不知有没有哪位大牛现身来做个总结呢？我以前看思一克和al*讨论得热火朝天的。怎么他们对这个不感兴趣了……

思一克

这个问题不好理想解决。
就是说不能将网络中断在个CPU平衡的太好。平衡的太好，网路传输反而慢了。因为TCP的特点是包有顺序性，后面的包不应该快到。而CPU并行的结果就打乱了顺序性。造成不该到的包先到，TCP协议中就要做RE-ORDER，RE-ORDER稍微多了，网络就慢了。再多，急剧变慢。

理想情况应该是按TCP连接在CPU之间平衡（一个连接的中断在一个CPU)。而不能是不管连接将网卡中断在CPU间平衡。

做NAT的机器的中断也不能在CPU之间平衡。自己机器无所谓，却给被服务的机器造成的无穷无尽的烦恼（不该到的先到问题）。

独孤九贱

原帖由 思一克 于 2009-5-19 14:18 发表
这个问题不好理想解决。
就是说不能将网络中断在个CPU平衡的太好。平衡的太好，网路传输反而慢了。因为TCP的特点是包有顺序性，后面的包不应该快到。而CPU并行的结果就打乱了顺序性。造成不该到的包先到，TCP协 ...

是呀，乱序太多，的确麻烦。我有想过如果是IP包的话，可以按不同的IP地址hash来用不同的CPU调度……
不过相对CPU的占用率，Netfilter才是大头，我更想在这上面节省点资源出来。现在这种一个CPU负责一个网卡的模式，只要配置得当，勉强也能接受了。

marsaber

我K
九贱出马，一个顶俩！

platinum

原帖由 思一克 于 2009-5-19 14:18 发表
这个问题不好理想解决。
就是说不能将网络中断在个CPU平衡的太好。平衡的太好，网路传输反而慢了。因为TCP的特点是包有顺序性，后面的包不应该快到。而CPU并行的结果就打乱了顺序性。造成不该到的包先到，TCP协 ...

若根据连接进行分担，而不是基于包的处理，这样做的均衡效果一定不如包均衡，但还会出现上面说的乱序导致重排，反而使网速降低的情况吗？

coneagoe

没有想过这个问题

terryfe

做了好久的SMP环境下的包转发，总结几点：
1. 对于普通网卡Linux协议栈无法进行实质上的多CPU负载均衡，需要支持RSS（多队列）的网卡，千兆比如intel 82575/6，万兆如intel 82598等。网卡对数据流进行hash然后分配到多个队列上，每个队列对应一个msi-x中断vector。这样就真正实现了多CPU同时处理协议栈。
2. linux内核从2.6.23开始支持多队列的网卡，到2.6.27才完整支持（仍需要hack达到性能最优），主要是NAPI结构的修改和Qdisc的多队列化。这种情况下在nehalem之前的平台上，万兆网卡测试转发时FSB成为瓶颈（多CPU争用）。
3. Nehalem可以解决FSB的问题，万兆多队列卡转发可以做到500万pps，此时PCIE的pps成为瓶颈。
4. 继续上升可能需要PCIE v2.0 的支持，或者像某些NP架构中使用专用总线避开PCIE的瓶颈。

思一克

原帖由 platinum 于 2009-5-19 21:06 发表

若根据连接进行分担，而不是基于包的处理，这样做的均衡效果一定不如包均衡，但还会出现上面说的乱序导致重排，反而使网速降低的情况吗？

基于连接的乱序就没有了。一个连接给一个CPU, 就基本没有后面的先到问题了（有一点是正常的，比如因为路由过程中的状况）。
基于包不管连接，那问题是相当严重。我实验过的。