如何让 linux 包转发达到 40万pps,尝试中！

colddawn

1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！

理解！不过这也证明目前市面上的很多国产设备的现状以及国内这个领域的研发状况，不做评价

2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p3 1G的CPU，64bytes下能到80M，我现在有好几台freebsd的机器，p4的和至强的，两边用光阵列机来跑，512bytes下才能到100M，64bytes下离你说的数据差得太远，因为没有条件，没有办法拿Smartbit来做测试，不过我想误差应该不会太离谱。

ok，我承认，我用的是P3 1G Xeon MP，PCI-X架构的pro 100网卡，以太网口。
同时我做的是透明网桥，包在2层就bridge走了，因此效率确实是比较好的，同时ipfw这个也是简单高效的代表，因此我相信我这套搭配应改在效率方面有较大的优势。
我测试的方法是发起100Mbps的synflood，这个应该是64bytes吧，如果全速情况下，我的设备能透过84M左右到达对端，也就是能保证80M不丢包。
我认为你测试达不到的原因可能在于你的光阵列，据我所知，光电转换后frame结构会改变的，跟以太网贞又很大区别，而光传输的优势在于高带宽高时延，但pps就不是很好，如果你用这这种设备，2次转换后应该会有折损的，具体细节我不是很了解，这只是推测。另外一个原因是你的设备的网络其他部分占用了较多cpu，例如ip层转发。我的设备在最高流量下cpu占用80%左右，打开网卡polling后降至40%，负载不会超过1，属于可以承受范围

3、目前intel架构的CPU网络数据处理与交换机的CPU等处理有质的差别，不能同一而论……否则大家做什么ASIC，做什么NP，拿一块p3不就完了……

这里我同意，ASIC的架构确实更适合一些，我的意思是目前CPU的指令处理速度应该不止于如此不堪。

4、至于性能不到，如果跑开软件不谈，光是谈硬件的话，我个人从经验来看，100M环境瓶颈主要在CPU，1000M则是一个综合的因素，目前PC架构在很多方面都无法满足1000M的大流量的处理。而如果要谈软件呢，linux和unix性能之别主要还是“其实是MBuf和skbuf的优劣，这是个老话题。……”


CPU确实有很大影响，但是我感觉在做好一定优化的基础上，i386绝对能胜任的。MBuf的问题就不讨论了，讨论那就是班门弄斧了。

caibird3rd

现在100Mb/s以下的流量已经不是问题了
我们的目标是千兆甚至更多
现在看来，通用的linux平台的确不能满足需要（这里不谈硬件部分）

谁能告诉我，linux在这方面有什么改进项目没有？或者有什么公司可以做这个事情？

另外，没看过MBuf的资料，它比skbuf好在哪里啊？哪位能点拨一二？

原帖由 colddawn 于 2005-11-22 09:16 发表



请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了linux+iptables再套个外壳实现的，要知道光netfilter架构处理占用的cpu时间就高达30%，如果再加上那个性能风传非常差的conntrack的话，这个结果不出奇，这并不能说明是总线瓶颈或者是cpu瓶颈，另一方面，即使是你说的35%的带宽利用率，你有统计过那时中断/s的数量吗？有证据证明是cpu中断处理不过来了吗？
linux的我倒真是没测试过，但是同样是p3 1G，板载pro 100，我装过freebsd，仅仅使用ipfw+bridge做透明防火墙，连内核都没有优化过，轻松达到80M，无延迟，无丢包，100%线速说不上，但90M的时候的丢包率也是基本可以忽略不计。
如果一个1000M包转发的设备都要用4路Xeon，那24口千兆三层交换或者路由器岂不是要大型机？  ...

[ 本帖最后由 caibird3rd 于 2005-11-23 09:55 编辑 ]

mirnshi

原帖由 独孤九贱 于 2005-11-22 09:37 发表


不太同意你的话：

1、我的报告是国家信息安全测评中心测试的，只是关系很多商家的利益，不敢乱贴，sorry！
2、请贴出你的freebsd能到80M讲给出测试环境，以及测试的包的大小，我不太相信p3 1G的CPU，64by ...

fps鲜有所闻，大家好像一般都是说pps。桢的概念似乎是通讯上的，包似乎是网络处理上的。

先看看操作系统如何处理包：
一般对于高效处理，很少是一个包一个中断的，都是通过轮询方式，比如在freebsd下，高负载情况下，
可以设置5000次/s(intel百兆卡，一般够用，至于怎么够用，自己算吧)甚至更高，网卡会将收到的包
存放于队列中，等待cpu的主动处理。这样中断数会极大降低。一般好的网卡比如常见的intel百兆卡，
(如果没有记错的话，队列大小是32，而8139才4)，可以缓冲大量的包，这样cpu的一次中断可以处理多
个包。在纯路由模式下，即使有少量的规则，包转发的速度是非常快的，基本可以达到线速的，当然
不是100M，所有的网络节点设备都会有延时的，只是多少而已。在防火墙中，消耗cpu的是nat和复杂的
规则检测，其他的基本功能消耗cpu比较少, 速度非常快，拿过一个包，通过指针定位ip头，根据ip头
定位动态规则表（hash检索），比较一下要么丢弃，要么直接送到下层。如果对协议栈了解的话，会
知道一个包从网络进入协议栈，大部分流程都是条件判断。
arp表，路由表之类的处理也非常快的，记得是3跳命中。再说了还有高速缓冲的，在freebsd中还可以
打开fastforward。mbuf使用起来也不像应用层的内存申请使用，不用担心那么耗费指令。对于包效验
和，汇编指令编写的，一般需要几十条指令，不会超过百条。

再看看CPU:
谈论到CPU，不能仅仅考虑频率。CPU的性能不能仅看频率，不同CPU的IPC也是不同的，众所周知的PIV
刚出来的时候还不如PIII，就是因为PIV的IPC不如PIII。而且现在CPU的IPC大都大于1，流水线技术不是
个摆设。还有就是PIII不等同于i686，i686只是一个指令集，支持i686的cpu很多，但是同代CPU中，PIII
是最强的。至于Cyrix的，是走低功耗市场的，性能嘛，不说了。

做程序，讲性能，不是简简单单的加减乘除，理论不等于实际。42%，莫非增加N多复杂规则检测？

mirnshi

目前对于百兆, CPU的速度足够，除非增加各种稀奇古怪的功能进去--什么各种代理过滤之类的。
对于千兆，由于pps增加了，网卡的队列也增加了，考虑到时延问题和中断，以及PCI通道问题，CPU就显得不够用了。内核支持SMP的，性能会提高很多。而且千兆很多都是桥模式的，最差也是路由模式，有哪个网管愿意在出口处，放个瓶颈？桥模式都是2层上作，省去了三层协议队列，当然处理时，需要自己构建协议栈了，包转到协议栈后，再由其他线程处理，分工合作。但无论怎样，受到PCI/X限制，也只能是当个假千兆用。
曾在Freebsd上作过测试，DDOS攻击，如果直接收包丢弃，可以达到8、900M，机器是PIV2.4至强，bsd 4.11，但是发包受限，优化得非常好了不过300多。

zyzf

X86的瓶颈就在网卡驱动上面。
个人觉得。

test_tmp

我也在做NAT,但还是新手,请楼主指点一下,如何达到5万PPS?还有如何测一台机器的PPS数
非常感谢

test_tmp

怎么没人理我

depthblue_xsc

我正在测试千兆防火墙的性能，64B双向达到线速的15%（30秒的测试时间）
如何能够再提高，系统如何再优化呢？netfilter的效率不高，linux的网络i/o分布不平衡
系统还有什么地方可以优化呢？

Solaris12

原帖由 mirnshi 于 2005-11-23 22:22 发表
目前对于百兆, CPU的速度足够，除非增加各种稀奇古怪的功能进去--什么各种代理过滤之类的。
对于千兆，由于pps增加了，网卡的队列也增加了，考虑到时延问题和中断，以及PCI通道问题，CPU就显得不够用了。内核支持 ...

100M/1000M现在OS一般都handle的了。

上1000个连接达到线速也是没问题的，不需要很强劲的机器。

但是10000M网卡就不一样了，这个需要特别的处理。

感兴趣的话，可以在solaris上测测万兆网卡。


因为本人不是搞防火墙的，所以不了解这方面的问题。

在100M/1000M上，CPU真的不是大问题。
而且先进的网卡都支持HW offload，很多工作不需要CPU来做。

当然这取决与你driver和OS是否充分利用了网卡的先进特性。


在intel e1000和broadcom的网卡上，都有类似的特性。

所以你的dirver和你的OS版本很重要，一定要用支持HW offload的版本

[ 本帖最后由 Solaris12 于 2005-12-15 17:39 编辑 ]

caibird3rd

现在的问题既不是网卡，也不是CPU
而是网络协议及其依赖的OS中断处理机制，而且网卡仅仅支持csum等简单的offload作用不大

原帖由 Solaris12 于 2005-12-15 17:32 发表


100M/1000M现在OS一般都handle的了。

上1000个连接达到线速也是没问题的，不需要很强劲的机器。

但是10000M网卡就不一样了，这个需要特别的处理。

感兴趣的话，可以在solaris上测测万兆网卡。


...

[ 本帖最后由 caibird3rd 于 2005-12-15 20:56 编辑 ]