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

colddawn

楼上说的正解，cpu指令集和总线架构是2回事，pci确实不行了，32bit，133Mhz，算算带宽百兆多点，稍微高点的应用就不行了，所以民用领域推出agp，服务器领域推出pci-X，但目前的趋势是统一回pci-E。
去intel的网站看看intel的网卡型号吧，824XX，825XX，总共几十个型号，都是有区别的，有pci的，有pci-X 66MHz的，有pci-X133Mhz的，还有pci-E的，甚至有dual port ，quard port的，说明一旦用上pci-X以上级别的总线，网卡绝对是能跑那么大带宽的，所以不必觉得X86不行了。

colddawn

sorry ，前面提供资料有误，现在更正一下，
最初PCI总线是32bit，33Mhz，这样带宽为133Mbps。
接着因为在服务器领域传输要求Intel把总线位数提高到64，这样又出现了2种PCI总线，分别为64bit/33Mhz和64bit/66Mhz，当然带宽分别翻倍了，为266Mbps和533Mbps，这个比较通常的名称应该是pci-64，但这好像是intel自己做的，没有行业标准。
稍后一段时间，在民用领域，单独开发出了AGP，32bit，66Mhz，这样带宽为266Mbps，再加上后来AGP2.0的2X和4X标准，最高4X的带宽高达1Gbps，但是这个只是为显卡设计的。
同时服务器领域也没闲着，几家厂商联合制定了PCI-X，这个就是真正PCI下一代的工业标准了，其实也没什么新意，就是64bit，133Mhz版本的PCI，那这样带宽就为1Gbps，后来PCI-X 2.0,3.0又分别提升频率，经历过266Mhz，533Mhz，甚至1GMhz，各位自己算带宽吧，我乘法学的不好，这个带宽可以说是非常足够的了，不过这个时候PCI也面临一些问题：一方面是频率提高造成的并行信号串扰，另一方面是共享式总线造成的资源争用，总之也就是说虽然规格上去了，但实际效果可能跑不了这些指标。
然后就是我们目前的明星pci-E了，这个标准应该是和pci-X同时出现的，但是由于当时用不到这么高带宽，并且不像pci-X一样兼容老pci板卡，所以一直没什么发展，直到最近民用领域显卡带宽又不够了，服务器领域对pci-X也觉得不爽了，pci-E才真正显出优势来，目前这个标准应该会替代agp和pci-X，成为民用和服务器两大领域的统一标准。
PCI-E标准的最大特点就是串行总线，和普通pci的区别类似于ide和sata的区别，具体说起来就比较麻烦了，简单来看指标的话，频率为2.5Ghz（这个恐怖，串行的好处，同样因为串行，位宽就没意义了，但是据说是什么8bit/10bit的传输），带宽 pci-E 1X单向传输250MBps，双向也就500了，同时pci-e的倍速最高可达16X，多少就自己乘吧，要注意的是pci-e不存在共享问题，也就是说挂在总线上的任何一个设备都会达到这个速度而不是所有设备带宽的总合。下面引用一篇文章的一段，感兴趣的自己看一下：

  在工作原理上，PCI Express与并行体系的PCI没有任何相似之处，它采用串行方式传输数据，而依靠高频率来获得高性能，因此PCI Express也一度被人称为“串行PCI”。由于串行传输不存在信号干扰，总线频率提升不受阻碍，PCI Express很顺利就达到2.5GHz的超高工作频率。其次，PCI Express采用全双工运作模式，最基本的PCI Express拥有4根传输线路，其中2线用于数据发送，2线用于数据接收，也就是发送数据和接收数据可以同时进行。相比之下，PCI总线和PCI-X总线在一个时钟周期内只能作单向数据传输，效率只有PCI Express的一半；加之PCI Express使用8b/10b编码的内嵌时钟技术，时钟信息被直接写入数据流中，这比PCI总线能更有效节省传输通道，提高传输效率。第三，PCI Express没有沿用传统的共享式结构，它采用点对点工作模式（Peer to Peer，也被简称为P2P），每个PCI Express设备都有自己的专用连接，这样就无需向整条总线申请带宽，避免多个设备争抢带宽的糟糕情形发生，而此种情况在共享架构的PCI系统中司空见惯。

    由于工作频率高达2.5GHz，最基本的PCI Express总线可提供的单向带宽便达到250MBps（2.5Gbps×1 B/8bit×8b/10b=250MBps），再考虑全双工运作，该总线的总带宽达到500MBps—这仅仅是最基本的PCI Express ×1模式。如果使用两个通道捆绑的×2模式，PCI Express便可提供1GBps的有效数据带宽。依此类推，PCI Express ×4、×8和×16模式的有效数据传输速率分别达到2GBps、4GBps和8GBps。这与PCI总线可怜的共享式133MBps速率形成极其鲜明的对比，更何况这些都还是每个PCI Express可独自占用的带宽。


总之写这么多废话，目的就是说明就系统总线来说，承受高带宽，高pps是没问题的。
再上面有人说即使总线没限制，cpu也会成为瓶颈，这话有一定道理，其实关键在于高pps带来的恐怖中断flood，其实对于这么高的中断，i386的apic（高级中断控制）是完全处理的来，瓶颈是在操作系统的中断处理程序上了，这方面问题就由操作系统来解决了，所以不是什么不可能完成的任务，实际上目前也都有很成熟的方案了，比如BSD系统的网卡Polling，Linux也有，具体叫什么我忘记了。
还是那句话，别对i386没信心，也别对目前的PC架构计算机的能力有任何怀疑，事实证明，这样的搭配至少能满足90%的应用需要。

colddawn

原帖由 caibird3rd 于 2005-11-18 15:51 发表
目前，linux作为一种通用的操作系统，
的确跟不上超高速网络流量处理的需求了
不知在这方面有什么linux的改进项目没有？
听说通过精简优化其TCP/IP堆栈可以获得近20%的性能提升，不知有没有这回事？
觉得关键 ...

优化协议栈的工作确实有人在搞，性能提升20%的说法只是听说，没见有实际证据，至于linux不能应付搞网络流量处理的问题，请问您是从哪里得来的？有没有实际数据？所谓高速网络高到什么程度？高流量还是高pps？

colddawn

原帖由 独孤九贱 于 2005-11-21 16:04 发表


偶见过许过权威的测试报告，测试过国内很多用linux作的防火墙、安全网关……等一大堆东东，用smartbit来测：
pIII 1G 的CPU，可以达到35%/64bytes左右。freebsd的话，稍好一点，不过也仅是“稍”；离线速差得 ...

请给出所谓权威报告的链接？谢谢！
国内很多防火墙是用了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口千兆三层交换或者路由器岂不是要大型机？

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的问题就不讨论了，讨论那就是班门弄斧了。