免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 独孤九贱

在多核系统上网络数据转发实验和一点思考 [复制链接]

论坛徽章:
0
发表于 2009-05-20 13:00 |显示全部楼层
原帖由 思一克 于 2009-5-20 12:39 发表


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

那么也就是说,如果是 IP 协议,简单根据 SIP/DIP,如果传输层是 TCP/UDP,那么再加上 SPORT/DPORT 的方式算出 hash 值,% 给 CPU_NUM
这样虽然做不到完美均衡,但在连接数多的环境中还是会相当有用的了!至少比什么都不做强得多

论坛徽章:
0
发表于 2009-05-20 13:08 |显示全部楼层
原帖由 platinum 于 2009-5-20 13:00 发表

那么也就是说,如果是 IP 协议,简单根据 SIP/DIP,如果传输层是 TCP/UDP,那么再加上 SPORT/DPORT 的方式算出 hash 值,% 给 CPU_NUM
这样虽然做不到完美均衡,但在连接数多的环境中还是会相当有用的了!至 ...


是的。不用完美。能避免绝大部份就可以了。
我做的那个网络软中断CPU并行就是你说的意思。

论坛徽章:
0
发表于 2009-05-20 13:30 |显示全部楼层
原帖由 terryfe 于 2009-5-20 10:17 发表
做了好久的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的瓶颈。
...



这是一种硬件方案。


软件上可以模拟这个方案,把RSS这种东西在协议栈级别实现,Solaris叫fanout, 基于连接来负载均衡。

[ 本帖最后由 Solaris12 于 2009-5-20 13:33 编辑 ]

论坛徽章:
0
发表于 2009-05-20 13:47 |显示全部楼层
原帖由 思一克 于 2009-5-20 13:08 发表


是的。不用完美。能避免绝大部份就可以了。
我做的那个网络软中断CPU并行就是你说的意思。


最近google提交了类似的patch,原理差不多

http://marc.info/?t=124140985500002&r=1&w=4

论坛徽章:
0
发表于 2009-05-20 16:33 |显示全部楼层
原帖由 Solaris12 于 2009-5-20 13:30 发表



这是一种硬件方案。


软件上可以模拟这个方案,把RSS这种东西在协议栈级别实现,Solaris叫fanout, 基于连接来负载均衡。


其实,我觉得软RSS的实现,在超过2个CPU核心以上才有意义。
或者说,这种均衡在CPU核心数量越多的情况下越有利。

不清楚Solaris上是否有类似Linux的netfilter conntrack来处理网络连接?

如果有的话,fanout和连接跟踪是否有结合呢?

论坛徽章:
0
发表于 2009-05-20 17:04 |显示全部楼层
/etc/sysctl.conf  改了后速度快了不少


# Controls IP packet forwarding
net.ipv4.ip_forward = 1
net.ipv4.tcp_fin_timeout=9
net.ipv4.tcp_max_tw_buckets =300
net.ipv4.tcp_tw_recycle=1

#VMfs

vm.drop_caches=3
vm.swappiness =100
vm.lowmem_reserve_ratio=16 16 4
vm.vfs_cache_pressure=163

#nfs
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
net.ipv4.udp_mem = 8388608 12582912 16777216
net.ipv4.udp_rmem_min=65536
net.ipv4.udp_wmem_min=65536
net.ipv4.tcp_window_scaling=1
net.ipv4.ip_local_port_range=1024 65535

论坛徽章:
0
发表于 2009-05-20 17:13 |显示全部楼层
原帖由 ShadowStar 于 2009-5-20 16:33 发表


其实,我觉得软RSS的实现,在超过2个CPU核心以上才有意义。
或者说,这种均衡在CPU核心数量越多的情况下越有利。

不清楚Solaris上是否有类似Linux的netfilter conntrack来处理网络连接?

如果有的话 ...

fanout机制确实是想多利用sparc的CMT技术,但是目前还是受制于PCIE总线的限制,至少我用ixgbe的硬件hash在opensolaris上只能做到160wpps(进行了大量hask....)。
NIU那块走专用总线的卡应该可以解决该问题,但是现在的内核协议栈支持好像还差不少....

软件实现的问题可能在于用于分发的CPU很可能成为瓶颈,因为同时只能有一个CPU来做这件事情,sparc的主频低啊== .....
不过一直没时间去试solaris在x86上软RSS实现的表现,不过想做到单机万兆线速只能上硬件了..

估计未来的nehalem架构+PCIE2.0的万兆RSS网卡可以接近极限

论坛徽章:
0
发表于 2009-05-20 17:38 |显示全部楼层
原帖由 terryfe 于 2009-5-20 17:13 发表
fanout机制确实是想多利用sparc的CMT技术,但是目前还是受制于PCIE总线的限制,至少我用ixgbe的硬件hash在opensolaris上只能做到160wpps(进行了大量hask....)。
NIU那块走专用总线的卡应该可以解决该问题,但是现在的内核协议栈支持好像还差不少....

软件实现的问题可能在于用于分发的CPU很可能成为瓶颈,因为同时只能有一个CPU来做这件事情,sparc的主频低啊== .....
不过一直没时间去试solaris在x86上软RSS实现的表现,不过想做到单机万兆线速只能上硬件了..
...


NIU + Crossbow的bug还很多呢。

如果是single ring的话, fanout的确是一个CPU做,但多个队列的时候,如果用pcitool把中断放到不同的core,理论上每个接收中断上来的CPU都可以做吧。

论坛徽章:
0
发表于 2009-05-20 17:50 |显示全部楼层
原帖由 Solaris12 于 2009-5-20 17:38 发表


NIU + Crossbow的bug还很多呢。

如果是single ring的话, fanout的确是一个CPU做,但多个队列的时候,如果用pcitool把中断放到不同的core,理论上每个接收中断上来的CPU都可以做吧。

前提就是硬件的多队列嘛。所以软RSS的实现在高压力下治标不治本啊...

论坛徽章:
0
发表于 2009-05-21 09:02 |显示全部楼层
现在有多队列网卡了。一个队列给一个CPU就可以。效果应该不错的。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP