精通polling参数调优的进来帮帮忙吧

caibird3rd

原帖由 xfsoul 于 2006-5-26 14:34 发表
我在PD 820和AMD Opteron平台，linux网桥透明转发。当包>512时候，双向千兆线速转发，轻松愉快！

现在的系统，包括linux和FB大包的性能都不错。我们还是要相信各位大牛地～
要显著提高小包性能，不在系统软件结构或者硬件平台上做工作是不太可能地～

colddawn

原帖由 雨丝风片 于 2006-5-26 09:57 发表


不是讨论是否需要使用、当时是否有必要设计cluster。我的意思很简单，系统是否使用mbuf链或者mcluster来存储网络数据都取决于mbuf的尺寸，既然把mbuf尺寸调整到足以存放楼主测试的全部数据，又何来“包在mbuf ...

cluster不光是用来存贮长度大的数据，同时还有引用计数器之类的设计思路，这样mbuf中可以注入和剥离各层的报头，cluster中存放数据，而不同层传递只需要引用到cluster的指针即可，如果纯粹使用mbuf，在各层中传递数据将会引发大量的mbuf中数据位移操作或者是mbuf拷贝，性能受到影响，所以即使mbuf足够大到可以存储整个包的数据，使用cluster还是有必要的。
但这里讨论的桥转发都是在二层处理，所以基本很少牵扯我说的这些操作，可能与主题无关。但同时也可能很少牵扯到mbuf本身数据的操作，只是mbuf链表的增删改，所以你加大mbuf大小的思路也基本影响不到性能，这就要到代码里求证了。

雨丝风片

原帖由 colddawn 于 2006-5-26 15:26 发表
cluster不光是用来存贮长度大的数据，同时还有引用计数器之类的设计思路，这样mbuf中可以注入和剥离各层的报头，cluster中存放数据，而不同层传递只需要引用到cluster的指针即可，如果纯粹使用mbuf，在各层中 ...

你说的有道理！

我原来是凭直觉，认为相对于mbuf链或者cluster而言，把数据放在一个mbuf中的效率就要好一些，因为“处理”似乎要简单一些，但好像这种流程上的东西确实也简单不了多少。从mbuf中的数据拷贝来讲，cluster确实比mbuf的效率要高得多：

1. 
   
2.                 if (m->m_flags & M_EXT) {
   
3.                         n->m_data = m->m_data + off;
   
4.                         n->m_ext = m->m_ext;
   
5.                         n->m_flags |= M_EXT;
   
6.                         MEXT_ADD_REF(m);
   
7.                         n->m_ext.ref_cnt = m->m_ext.ref_cnt;
   
8.                 } else
   
9.                         bcopy(mtod(m, caddr_t)+off, mtod(n, caddr_t),
   
10.                             (u_int)n->m_len);
    

复制代码

www_ftp

测试时发现:HZ burst_max等增大时 kern.polling.burst 会自己变小.导致系统每秒取的包的总数基本不变,造成大量包丢失.然后此时系统负载及cpu占用还都比较低.不知算法哪儿出问题了.

xfsoul

原帖由 www_ftp 于 2006-5-26 16:20 发表
测试时发现:HZ burst_max等增大时 kern.polling.burst 会自己变小.导致系统每秒取的包的总数基本不变,造成大量包丢失.然后此时系统负载及cpu占用还都比较低.不知算法哪儿出问题了.

嗯 的确是这样。kern.polling.burst的确会自动变的非常小。导致性能上不去。
不过当kern.polling.burst比较大（比方500），HZ=4000，这个时候按说包速可以比较大，可是性能也不行。

非常希望大家能把问题分析清楚。
网络性能对一个网络操作系统来说可是非常重要的啊！

www_ftp

原帖由 xfsoul 于 2006-5-26 16:25 发表


嗯 的确是这样。kern.polling.burst的确会自动变的非常小。导致性能上不去。
不过当kern.polling.burst比较大（比方500），HZ=4000，这个时候按说包速可以比较大，可是性能也不行。

非常希望大家能把问题 ...

是呀,这个问题的确很重要,要解决这个问题必须有多位牛人共同努力.实际测试中还发现两个问题,把polling升级到最新,也没有任何性能上的提高.6.0 6.1都有个打开polling在极限下假死机的现象,现象是打开polling,收受大量的小量,这时cpu 100%,然后减低小包数量,也自己恢复不过处于假死机状态.6.1RC1就不存在这个问题,只要减小包的数量,自己马上恢复,不存在假死机状态.

xie_minix

www_ftp老弟.请贴出机器的配置情况.谢谢

zjzf_2

freebsd 6.0的 polling 的确没有什么效果 这个我进行了反复的测试

82546网卡freebsd4.11 打开polling  hz=1000  p42.8 64bytes的报转发率可以到500m以上

而换了freebsd6.0 只能到250M
polling SMP AMD64 我都测试过   非常遗憾无法突破300m  

顺便告诉你 我没有用什么netbsd移植过来的if_bridge              也没有用freebsd原有的的bridge  根本不是bridge的问题

热心的老大 Dennis2  帮我找了篇文章 New Networking Features in FreeBSD 6.0
文中提到
The first go on fine-grained network locking in
FreeBSD 5 has been greatly enhanced and
refined for excellent SMP scalability. For single
processor machines all performance regressions
due to locking overhead have been eleminated
and FreeBSD 6 reaches the same speed in heavy
duty network streaming as the FreeBSD 4 series.
但是实际上freebsd 6并不能带给我们昔日强劲的包转发性能

我也开始怀疑是过多的mutex降低了效率    但是为了坚守bsd阵营 我尝试了DragonFly
DragonFly自称是freebsd4.9的延续   
DragonFly的包转发性能可以说是强于freebsd6.x的 我在相同的硬件上可以达到300m 但是较freebsd4.11还是相差太远

目前我个人认为 驱动程序是一个 非常重要的因素   因为linux也曾出现过新驱动包转发性能下降的问题

我还在继续关注并尝试解决这个问题

另外提醒大家 类似问题不要总想着高手能给你一个完美的答案

谢老师也在这里 好久没见您
Dennis2老大 帮我找了些资料其中包括这个
http://proj.sunet.se/LSR3-s/   netbsd在万兆以太网创下的一个纪录 不过我想小包才能说明问题

另外netbsd 曾经有人做过polling方面的工作 希望能给您带来帮助http://thir.org/thir/NetBSD/devicepolling.en.html


最后提议下  多处理器的工作 大家都盯着对称多处理在想   我觉得解决包转发这种对问题应该朝着非对称多处理多想想 当然这个难度不小

[ 本帖最后由 zjzf_2 于 2006-5-26 20:46 编辑 ]

www_ftp

原帖由 xie_minix 于 2006-5-26 17:05 发表
www_ftp老弟.请贴出机器的配置情况.谢谢

Intel(R) Pentium(R) 4 CPU 3.00GHz

real memory  = 1065287680 (1015 MB)

avail memory = 945688576 (901 MB)

Intel82547EI  CSA

xfsoul

最新测试结果出炉，数据没有经过整理，太忙了，呵呵。
测试硬件平台：
CPU： 双Opteron 250（运行频率2.4G）
内存：DDR400 双通道（ECC关闭）
网卡：Intel双口千兆网卡
Smartbit千兆口两个
Smartwindow 9.0

linux 2.6.9(redhat enterprise linux 4 update1)
包长   带宽        包速(pps)  字节速率(Mbps)    CPU占用
64     18.3%       259875     141.37            86%
128    30.46%      250501     264.54            94.5%
256    56.45%      250016     524.19            96%
512    89.93%      209732     865.77            80%
1024   100%        119274     980.91            40%
1500   100%        82020      986.86            29.5%
混包   43.97%      401.36     239825            93.5%


FreeBSD 4.11(polling enable，HZ=4000)
包长   带宽        包速(pps)  字节速率(Mbps)    CPU占用
64     32.6%       462963     251.85            1%
128    48.87%      401929     424.44            1%
256    66.35%      296209     616.11            1%
512    84.94%      198098     817.75            0%
1024   100.0%      119274     980.91            0%
1500   100%        82020      986.86            0%
混包   60.26%      328831     549.97            0%        


FreeBSD 6.0 (polling disabled， if_bridge)
包长   带宽        包速(pps)  字节速率(Mbps)    CPU占用
64     22.98%      326371     177.55            93%
128    38.48%      316456     334.18            97%
256    65.88%      294118     611.77            87%
512    84.54%      197161     813.88            32%
1024   100%        119274     980.91            22.5%
1500   100%        82020      986.86            17.5%
混包   57.97%      316351     529.09            88%


FreeBSD 6.0 (polling disabled， BRIDGE)
包长   带宽        包速(pps)  字节速率(Mbps)    CPU占用
64     26.43%      375375      204.20           95%
128    44.44%      365497      385.96           93%
256    65.88%      294118      611.77           61%
512    84.54%      197161      813.88           30%
1024   100%        119274     980.91            22.8%
1500   100%        82020      986.86            17%      
混包   59.48%      324561      542.83           82%

[ 本帖最后由 xfsoul 于 2006-5-31 08:58 编辑 ]