“软件路由器破速度记录”有91个回复

1. bigrong 于 2010-08-29 8:22 下午

   http://shader.kaist.edu/packetshader/
   谢谢首席，上面链接是我找到的资源，但是没仔细看。
   听听大家的看法。

2. 打酱油的 于 2010-08-29 8:37 下午

   赞一个。看好通用处理器+并行的组合。

3. asr1000 于 2010-08-29 8:57 下午

   功耗呢？

4. 过客 于 2010-08-29 10:03 下午

   只是说带宽达到40G没有意义。。。大包的情况，弄台强点的服务器，插几块10G的网卡就搞定了，需要研究么？关键是转发包速率，小包也能到40G就牛逼了。公布下包速率的转发数据呀。。。能到3G线速么？

5. sharang 于 2010-08-29 11:02 下午

   小包也能达到.

   论文中64b包的吞吐量也几乎是40G

6. 一条虫 于 2010-08-30 12:08 上午

   警惕韩国人造假。

7. 一条虫 于 2010-08-30 12:10 上午

   哎呀，失误，没仔细看，用GPU!这个idea我还想过呢……足够的存储带宽和类似的处理方式！

8. gaohl 于 2010-08-30 12:41 上午

   我不相信小包能到40G水平（30G线速64B），大包没有什么可以骄傲的。

9. Panabit 于 2010-08-30 1:02 上午

   的确牛！论文中的很多IDEA我在实际中验证过，不过40G的确出我意料之外，我以为10G应该是没问题的。OK，我们看能不能直接使用X86做一个10G小包线速的路由器看看，呵呵。

10. bigrong 于 2010-08-30 1:14 上午

    楼上的做出来，我们关注啊！
    别忘了告诉我们是哪个牌子的显卡！

11. swimmingbear 于 2010-08-30 2:09 上午

    路由器性质注定会转入封闭系统，即使40G转发也不可能商用。

12. alrn 于 2010-08-30 5:58 下午

    不明白,如果仅仅是转发,处理包头,还是有可能的,我们的router不仅仅是转发,IPSEC,SSL处理需要大量的CPU资源,本文都说明….一头雾水!

13. alrn 于 2010-08-30 5:59 下午

    不明白,如果仅仅是转发,处理包头,还是有可能的,我们的router不仅仅是转发,IPSEC,SSL处理需要大量的CPU资源,本文都没有说明….一头雾水!

14. droplet 于 2010-08-30 8:54 下午

    最好能把程序贴出来看看，加密，解密需要结算，但是IPS之类，还是内存访问比较多，用GPU怎么编这个程序？

15. aaa 于 2010-08-30 9:25 下午

    感觉就是在忽悠，一向觉得棒子没啥智商，唱唱歌跳跳舞整整容赚点钱就得了
    有本事把架构图贴出来。。扒光丫衣服

16. iWalle 于 2010-08-30 9:31 下午

    GPU也是有大缓存的，即显存。

17. 陈怀临 于 2010-08-30 9:36 下午

    软件路由器 + 40G这两个参数其实是违背生态链的。目前switch的端口还是在主打10G端口。40G的软件路由器如何与switch互联，组网，。。。，这才是大问题。

    做software based 10Gbps switch是一个路子。。。但每个月的电费，高丽棒子要想清楚。。。

18. iWalle 于 2010-08-30 10:14 下午

    还是看直接看他们的sigcomm 2010论文比较清楚。里面有IPsec的测试数据。64B为10Gbps。GPU负责加密解密。我觉得idea很清楚，即利用GPU实现包的并行处理。因为GPU是SIMD架构，所以只要这些包需要同样的执行指令，即可在一个指令周期内并行处理。只要GPU的能力足够,IO带宽足够，40G是没问题的。但是其中的trick就是，执行相同处理的包数量要够多，从而能充分发挥GPU的能力。他们并没有提供混合业务的测试数据。

19. asr1k 于 2010-08-31 7:27 上午

    很好的一个例子. 大概去年的时候无聊玩了一段时间的cuda. 后来也使用过cuda-engine. 总体来说想法还是不错的. 至于service routing, 是个很好玩的东西. 可以外挂在一些FPGA based的平台上, 做成LC可能还需要考虑功耗情况, 外置可能更妥当, 例如2U-4U的一个chassis. 然后10Gbps和这些传统平台相连. 报文查找和转发还是靠FPGA/TCAM一类的东西玩. 而这些, 则是在报文重新封装一些service-tag后扔到外置的box上处理一圈再回来丢出去就行了. 例如DPI, ALG, IPsec这些该死的东西早就该扔出来搞了. 而且CUDA嘛, C code弄起来也方便.

    软件路由器倒是一个很好玩的东西, 某些家也在做…呵呵…

20. bigrong 于 2010-08-31 6:19 下午

    就喜欢这种扔块骨头，大家一起咀嚼的感觉。

21. Panabit 于 2010-09-01 5:43 上午

    会楼上的，我陪你咀嚼一下，呵呵。这几天在调试驱动和多核，有不少体会和提升，我会在后续做10G的过程中逐步去提高。10G的话，不一定需要GPU，我先做做看，至少先将纯桥转发的性能测试出来，也可以。

22. 一颗树 于 2010-09-01 6:22 上午

    panabit兄，有啥体会也分享一点啊。我的经验来看，现有的服务器加网卡要做到10G线速还是很不容易的哦。

23. JustDoIt 于 2010-09-01 6:26 上午

    纯桥接做到万兆转发一年前就有人做出来了，主要是三个问题：
    1.重写Intel的万兆驱动，因为在高PPS情况下太多Lock contention，无法使用
    2.重写桥接，从single threaded转到能较好的支持multithreading
    3.如果在FreeBSD上做，优化SMP mutex

24. asr1k 于 2010-09-01 6:59 上午

    桥接其实没有意义的, 路由查表也没有意义. 大概就是一些复杂的逻辑, 可以用这个来处理. 例如SBC, DPI, IPS, ALG这样的东西. 这些东西ASIC来做真的太烦人了. 还不如封装好, offload过来在这些PC上处理完了扔回去.

    特别是加密这样的东西, Nitrox 2 的性能也就20Gbps的IPsec吧. 如果选用CUDA, 一方面API可以选用engine-cuda的openssl.这样复用一些其他的code就容易了. 很容易做到10G, 而且价格远低于 Nitrox 2. 编程实现也容易.

25. Panabit 于 2010-09-01 7:31 上午

    嗯，是的。一步一步来，桥接能做到20G是一个前提，这个步骤主要是用来衡量硬件IO和驱动的匹配能力。

26. Panabit 于 2010-09-01 7:36 上午

    问一下23楼的兄弟：是64bytes小包20G线速吗？能告诉我是什么样的硬件配置吗？说实话，我只是评估过这种可能，但是还没有实现出来。目前评估的结果是，单核可以做到6Mpps左右，但是我不太清楚多核同时运行得时候，内存的瓶颈有多大。

27. JustDoIt 于 2010-09-01 7:47 上午

    2*X5570
    20G的64小包线速，CPU是15%

28. asr1k 于 2010-09-01 8:22 上午

    看样子是nehalem的架构了? DDR3 ? 内存带宽差不多接近30Gbps.

29. Lucifer 于 2010-09-01 10:21 上午

    X5570是nehalem-EP，2.93GHz，内存应该是三通道DDR3-1333吧

30. 阿牛 于 2010-09-01 12:47 下午

    X5570内存带宽 30GB/s

31. 一颗数 于 2010-09-01 6:25 下午

    JustDoIt兄，你23楼提到的，有论文或者其他什么详细一点的资料吗？

32. 理客 于 2010-09-01 10:42 下午

    目前商用的40G级别的商用多业务路由器，是叠加了多少chipset才搞出来的。
    用通用多核做指定业务的路由器是可以的，或者做10G以下的多业务路由器，10G以上的多业务路由器，至少从目前的商用技术看，还不可能，也许5年后有创新的技术到商业，也未可知

33. 星空 于 2011-11-10 2:31 上午

    飘过路过。

    论坛里被Tom说Out了，看来真的out了，还不是一星半点。

    对10G的线速还是有点疑问：是不是仅完成单一的任务下才能做到10G线速？

34. 懵懵懂懂来请教 于 2011-11-10 6:16 上午

    各位大侠，用来测试硬件性能的纯桥是什么，请点播一下，谢谢。　

35. multithreaded 于 2011-11-10 8:15 上午

    你的问题要具体点。 是IPv4 forwarding or or IPSec or SSL?

    韩国人的工作有点意思，但是基于Intel 82599 io_engine不是很稳定，经常挂了。

36. 懵懵懂懂来请教 于 2011-11-10 8:30 上午

    multithreaded， 你好， 你说的任何一种都可以。 我的意思是，比如测定两种不同平台845 和 G41的硬件的IPv4 forwarding性能，应该安装什么系统，不可能是标准LINUX吧。

37. 路过 于 2011-11-10 12:01 下午

    纯属炒作

38. sailing 于 2011-11-10 3:40 下午

    40G 64B小包线速在Nehalem或者Sandy Bridge上，即便可以平均Amortize到8个核上，即便所有的报文都可以直接进入最后一级Cache，没有Lock Contension，也非常难以实现，即便是简单的桥接。可以精确的计算出一个CPU需要多少个Cycle处理一个报文。

    目前用Sandy Bridge+FPGA+PCIe做网络处理的一些大的厂商还是很多。PCIe 3.0出来后将会更加普及。不认为用GPU可以加速报文转发能力，做某类处理可能可以。

    目前继续看好Sandybridge+PCIe+FPGA做这类设备，而不是多核处理器。主要原因是Sandybridge在Memory Subsystem上的表现更胜一筹。

39. Panabit 于 2011-11-10 5:54 下午

    1) 文章里的GPU主要用来做加解密的

    2）在X86下，40G 64B小包路由是完全可以实现的

40. 根本不相干 于 2011-11-10 5:55 下午

    对楼上40G线速转发的一点探讨

    1) 理论计算：以Xeon 5645 (westmere, 6 core, 2.4G)为例，每10G小包对应14.4Mpps，40G分摊到6 core上每个core需要处理9.6Mpps，相当于2.4G/9.6M = 250 cycle / packet，基本相当于简单的IP Routing & Forwarding (算法和流程优化是为200 cycle)

    2) 第三方实测结果，单颗桌面CPU纯转发达到30G，但通过内存超频则达到最大接口带宽40G(没法贴图，只好贴文字了)：Forwarding
    performance is around 30 Gbps, and is lower than RX and
    TX throughput. Since QPI and PCIe bus are full-duplex links,
    I/O should not be the problem. We find that the forwarding
    performance in the desktop scenario is limited by the memory
    bottleneck. We explain further details in the following section.

    In Figure 5, we see that the forwarding throughput is lower
    than that of RX and TX due to insufficient memory bandwidth.
    We find that (i) CPU usage for forwarding is 100% regardless
    of packet sizes and load/store memory stall wastes most
    CPU cycles and (ii) with memory overclocking to have more
    memory bandwidth, we improve the forwarding performance
    close to 40 Gbps.

    ——–to be continue—————

41. 根本不相干 于 2011-11-10 5:55 下午

    —————continued——————-

    3）在前面一篇经典文章（给力吧X86-实测12.13），著名的Panabit同学基于ATOM平台研究有以下论述：

    Panabit 于 2011-03-08 2:24 上午

    从我们自己评估结果看，一个Core应该可以做到小包8G线速的，就是说大概12Mpps。一个Core裸奔做到10Mpps，其实也是不错的结果了。双核目前可以超过20Mpps。系统的瓶颈不在CPU，而是在总线的TRANSACTION速率上。我们后面的“给力吧，X86“系列会一步一步的告诉大家不同的X86芯片组和网卡组合的硬件性能评估结果，敬请大家期待。目前已经评估了N270，D525，下一步会继续评估G41，Q35，3010，3210,3420，Q57，5000P，5520，以及最新的Sandy Bridge芯片组。网卡方面，我们会将Intel目前常用的所有的PCIE千M网卡，如82571/2/3/4/5/6，82583,82580已经Intel的万M网卡82598和82599也统一评估。

    ————————–

    所以总结一下：

    1) 40G的IO和裸奔转发，对单颗多核Xeon而言根本不是问题，这还仅仅是当前PCIE2

    2) 40G的IP路由，理论计算CPU cycle刚够，但不清楚对访存压力的影响。棒子扔给GPU其实某种程度也是利用显存来解救主存压力(我个人觉得这个意义说不定要大于所谓GPU并行计算意义)。当然如果Cache调度利用得好，CPU也是有可能完成的，但需要测试（我知道已经有人在做类似的事情）

    3) 对于更复杂的L4-L7，以及VPN/Tunnel封包等，需要的CPU cycle从1K-15K以上不等，需要co-processor来加速特定算法。棒子的GPU是一个思路，当然专用FPGA也可以，Intel也在CPU里集成加速器，比如AES-NI效果就相当不错(有测试单个2.66G core加密能达到5G，解密能达到15G)

42. 根本不相干 于 2011-11-10 6:07 下午

    我在想一个问题：

    基于ivybridge平台，PCIE 3.0 X16（或2个X8），四通道DDR3 2133，能不能单颗CPU做到80G simple routing？（接口NIC为双端口40GE，或四块2×10GE）

43. 阿土仔 于 2011-11-10 7:27 下午

    转发的速度不能只看CPU的指令多少，还要看内存的处理，不是内存IO越快，查表就能够越快的。目前的cache也没有那么大。单打一条流或几条流没有意义，速度快是都被cache住了。

44. Panabit 于 2011-11-10 8:00 下午

    同意阿土的观点，不能仅仅看CPU，内存子系统是关键，CPU往往不会成为瓶颈。不过目前大家应该看到X86在IO方面的飞速进步。

45. multithreaded 于 2011-11-10 11:25 下午

    >1) 40G的IO和裸奔转发，对单颗多核Xeon而言根本不是问题，这还仅仅是当前PCIE2

    恰恰相反，主要的瓶颈口是IO。 请用io_engine 0.2 测一下就知道了。

46. sailing 于 2011-11-11 1:40 上午

    部分同意multithreaded。因为我不知道他的I/O是不是包括整个Memory Subsystem，如果是，就同意。

    单纯说设备I/O。简单算算x86的PCIe 2.0能提供的带宽就知道了。

    以8 Lane 5GT/s为例。
    有效带宽过8/10编码后，剩32Gb，物理层和链路层协议还有一定的开销。网络传送本身的开销，比如Multi-Ring Buffer管理，缓冲管理，流控，保序等还有一堆开销，能剩25Gb就不错。根本不够40G。

    PCIe 3.0时代也就刚好吧。如果考虑存储器访问，运算是永恒的瓶颈，光一个统计就得用很多资源。考虑网络报文处理是Weak Locality，Cache很难用得很好。

    CPU不是瓶颈，那得看是做什么用途。如果收了包，简单转发，我看连CPU都不需要，直接在FPGA里面做就行，外面找颗最弱的MIPS做基本控制即可。使用CPU就是需要进一步做逻辑不方便做的处理工作。实际上Verilog不方便做在某种程度上也说明用C实现的效率也不会太高。

    目前FPGA在设计中也有很实际的问题，直接用Intel的网卡做Networking infrastructure级别的设备可以想想，但是在前面也要加额外的处理。

    40G的设备用FPGA，内部总线至少得用256b，即便用K7也不好设计(我简单验证过），用ASIC挺好，就是40G设备目前没有到达这个规模，性价比并不高。

    一堆问题，挺头痛的。同意首席之前说过的把这东西能用CPU做好，就是Cache那点事，but how? x86的Cache Hierarchy没有那么好控制。

    前一阵和某司讨论了一堆很细节的问题，天天头痛。唯一感到不头痛的是，IT与网络领域的迅速融合，很多人已经开始不是天天谈小包线速了。

    依然看好Intel x86+PCIe 3.0+FPGA的方案。虽然也不容易。

47. Panabit 于 2011-11-11 2:03 上午

    楼上怎么计算的？现在的CPU基本上都至少提供一条X16的PCIE。40G带宽根本就是小菜，multithreaded的意思肯能是说小包不够。大包随随便便就可以超过40G，就看单路的C206，大包都远超过50Gbps。

48. Panabit 于 2011-11-11 2:07 上午

    内存的问题，无论是在ASIC，还是在FPGA，都是存在的，除非你的ASIC或FPGA做的事情非常简单或使用较小的SRAM。

49. sailing 于 2011-11-11 2:12 上午

    我算的是×8的，你非得说×16的。那天见面和你仔细说吧。这里不是争论的地方。用FPGA，有些报文就不会进入主存储器了。

50. sailing 于 2011-11-11 2:15 上午

    Sandy Bridge本身就可以提供40个Lane，看如何搭建了，争论这个没有意义。

51. 根本不相干 于 2011-11-11 4:07 上午

    sailing的意思，是不是找支持SNB平台x16或2个x8的外围芯片组很难找？或者很贵？要不为什么非要坚持用x8算呢，好像我前面并没有加这个限制条件啊？

    当然如果支持2个x8或x16的芯片组很少或巨贵，那另当别论，即使理论可行，也没有商用价值

52. 根本不相干 于 2011-11-11 4:09 上午

    关于内存带宽问题，我目前按端口速率X4计算，感觉40G对三通道而言应该刚刚能满足。能否请各位有经验人士提供些更细的数据，讨论下内存带宽的制约瓶颈？

53. sailing 于 2011-11-11 5:03 上午

    首先不考虑直接用Intel和BCM的40G网卡的方案和相关的应用。

    哪里能找到支持×16 Lane的FPGA。有×8接口的FPGA至少我用不起，后来知道几个超级通信大厂原来也舍不得用。现实一点是一个FPGA用两个×4的Lane与Sandy Bridge相连。这样用4个FPGA才能用到32个Lane，估计还不容易放下。

    因为在一个系统中，基本上都用2个Sandy Bridge，每套Sandy Bridge加上2个FPGA，在一个通信标准板，可以是ATCA，功耗Margin基本上用完了。而且再多的FPGA Layout也不容易，布局估计都布不开。

    等PCIe 3.0和性能更高的FPGA去解决40G，我之前算过。有些东西都是具体实现的取舍，有很多细节，可以专门开个会讨论好几周了。

54. 理客 于 2011-11-11 5:07 上午

    如果intel CPU在计算能力/IO能力/cache能力上都能达到40G，那为什么C/J/A/H一直都非常坚持自己的N*10G-100G的套片？而intel在撤出其IXP系列NP市场后，也没有看到任何用多核做路由器市场的打算？是intel CPU的功耗和价格不给力？还是怕被intel控制？还是就是要用自己的芯片提高价格多卖钱？这里面一定有真实的原因，或者说某些观点是能经得住考验的，有些不是，或者说还有一些正确的观点没有被挖出来。
    之前有一个很长的讨论NP的帖子，里面X11的高手cover住了绝大部分问题，但是，为什么思科不选X11，选EZCHIP？现在X11的市场如何了？
    就像股市一样，如果不是对这方面真的能把握的够，还不如跟大户，对不懂某个专业的人，学会如何跟大户，比钻入自己一时半会难以搞懂的技术细节更重要。
    如果不支持VPN，这样的设备在10年前确实是路由器但现在一般都被称为交换机，好一点的叫L3交换机，很少再叫路由器了。
    比较同意sailing的看法。

55. 根本不相干 于 2011-11-11 5:51 上午

    to 理科 and sailing

    我承认你们说得非常有道理。事实上通常来说，你们的观点非常自然，从做产品角度而言也是低风险的优选方案。不过，我这里插进来，是出于一些特殊的背景考虑(很抱歉暂时不方便细讲)，目的在于和大家探讨一下技术可行性，而不涉及好不好或者优不优。

    另外就是先强调一点，这里想探讨的X86，确切说是大众化的X86系统，不是指Intel(非X86任何产品包括X11)，也不是X86 ISA(自己用x86芯片设计专门硬件板子)。整个体系只考虑能直接从市面上买到现成的。

    另外请sailing注意一点，我前面的假设是“单路”SNB哦。也许不符合常规思路，但这的确是我想探讨的话题，即单颗SNB系统能处理多少G转发。还有就是你恰恰直接否定了我的假设，我的设想恰恰是直接买两块双端口10GE网卡，接在芯片组的X8+X8上面，结果被您的假设直接给否了:)

    OK,现在明确的说，单颗SNB配合支持X8+X8的芯片组(这个我查了桌面级都大把很便宜)，然后插两块2×10GE卡(每个x8插一块)，构成我设想的40GE目标系统，能否搞定64字节线速路由？我前面贴的文章节选已经说明通过对三通道DDR3 1333超频，可以实现40GE线速转发，假定没有学术造假，那就说明IO和forwarding已经不是瓶颈了。下面要解决的是routing时查表线速，通过理论计算感觉cycle问题不大，但是有没有其它瓶颈，能否解决？上面的结论是否成立或者第三方实验结果是否可靠，则是我想拿出来探讨的问题。

56. 根本不相干 于 2011-11-11 6:11 上午

    补充明确下吧，假设目标系统为SNB E5 1620（$294, 四通道DDR3 1333，4核8线程3.6G，LLC 10M）；或者桌面CPU i7 3820，规格基本一样，但内存为四通道1600，带宽增20%。

    这样选择的原因是比较主流，性能也不错，性价比高，配套芯片组和主板多。某些实验一上来去挑选动辄上千刀的高端CPU，去证明X86的能力，毫无意义。

57. 理客 于 2011-11-11 6:32 上午

    这是个很好的方向，panabit应该有已经有相当的结果的。我可以说是不懂技术的，所以只从市场的角度看：做某些专用网关可以，但做通用路由器，性能应在在10G左右，40G是不可能的。

58. multithreaded 于 2011-11-11 6:49 上午

    童鞋们，看样子，不是每人对“棒子”的文章精读过， 有必要“科普”一下. 鄙人认为，PacketShade 有如下贡献：

    1。 修改内核驱动，开辟了一条从网卡到内存的高速通道。大概单queue可以达到10MPPS。 这是最大的贡献：-）

    2。技巧性的利用prefecth较好的解决了“Cache”的那点事。对prefecth感兴趣的人，要好好向”棒子”学习。

    3。“欺骗“性的把报文以批处里（Batch Processing）的方式踢给了GPU，”彻底“地解决了memory wall 的问题。 但这对IPv4 forwarding 来说是不可取的，应为它大大加大了报文在系统里呆的时间。

    4。所谓的转发性能，只测到几千条flows而已，都在Cache面，不要当回事：-（ 学术界能做到这一步已经是很不错了）

    5。用的是Intel 82599 网卡(PCIe2.0，x8). 请不要谈 x16的网卡，它还是”神马浮云“。

59. 11.11.11 于 2011-11-11 6:53 上午

    超级光棍节，大家还这么用心刻苦啊。

60. multithreaded 于 2011-11-11 7:02 上午

    〉OK,现在明确的说，单颗SNB配合支持X8+X8的芯片组(这个我查了桌面级都大把很便宜)，然后插两块2×10GE卡(每个x8插一块)，构成我设想的40GE目标系统，能否搞定64字节线速路由？

    It depends …. Please think about

    (1) IO, whether you can hack the Intel 82599 driver and make its mutiple-queue stable. Or buy very expensive IO cards like Endac ones.

    (2) Cache
    If the routing in 8MB L3 cache
    yes
    Else
    ????

61. 根本不相干 于 2011-11-11 7:29 上午

    thanks， multithreaded

    1) Yes we have very skilled people hacking the NIC driver

    2) Our sceneary is not core router, and the routing table is very small.

    Anyway, 40G line-rate of 64byte IP routing is not our target system spec, but it’s a start to evalute the X86 pure forwarding performance. Maybe L4-L7 including VPN tunnel is the real service model, and how about the performance for a uni-processor x86?

62. 理客 于 2011-11-11 8:55 上午

    作为全球都用的intel CPU，发展真是太快了。8M cache，用好了，应该可以玩大的了，做40G应该有可能，但需要配合查表引擎和TM，这样下来，3820的功耗可能有点大，成本可能也会和使用NP/ASIC方案的差不多，看来性能可能是可以达到的，但从成本、功耗和保证线速下增加功能对系统的影响度，从目前看可能还没有明显的优势。
    从早期CPU根本没法用在高性能网络设备，到现在的可用，再发展下去，intel CPU很可能可以做中端通用路由器，你和panabit做的方向很有意义，应该有前途

63. Multithreaded 于 2011-11-11 11:23 上午

    是的， 大辽国排名第一的网络公司有一个团队在做这个方向的研究。 我大宋排名靠前的公司好像还在观望， 没有具体的行动。 估计是缺乏hack Linux的决心， 太依靠Intel的DPDK 上了。

64. kevint 于 2011-11-11 2:23 下午

    dpdk is a hack of linux already

65. 阿土仔 于 2011-11-11 7:19 下午

    DDR3的IO速度确实非常快，达到payload的存取速度是没有任何问题的，但是其对于查表的短操作是有限制的，因此查表带宽是最大的瓶颈。这也是为什么网络NP为了保证线速，大量的采用了QDR2，RLDRAM，内部SRAM等的原因。

66. 阿土仔 于 2011-11-11 7:31 下午

    另外，使用Intel的处理器还要配高速网卡芯片，82599一点儿都不便宜，其实加起来的成本已经非常高了，而且还要占板子面积。X86的优点是对于大多数中小厂家来说，硬件不用投入开发，且CPU更新换代非常快，很容易靠CPU来提升性能，且性能就算小包不线速，但也是挺快的。从技术上来说，处理数据包和通用处理还是不一样的，比如说NP尽量把高速表项查找和TM等做进去，多核把加解密，压缩，DPI等做进去，如果X86也把这个集成到一颗CPU中，也会影响其CPU内核和cache，大家都差不多。

67. 根本不相干 于 2011-11-11 10:09 下午

    呵呵看来这个贴很热闹啊，没想到对这块关心的还不少。从道理上讲，专门为网络优化设计的NP或多核CPU一定在性能功耗效率上强于X86，这个根本不用讨论，我想没人会去否认这一点。其实我突发奇想借这个贴子的宝地是想探讨一下：到底今天的X86能做到什么程度？还多多大差距？这种差距是数十倍、数倍、还是百分之几十？差距的趋势在扩大还是缩小？这些是我主要关心的问题。

    其实上面的讨论基本明确了我的判断：这一代SNB在40G级别以下IO裸奔不是瓶颈，相反业务处理构成瓶颈。而这个业务处理瓶颈来自于两个方面：内存transaction，以及CPU cycle。象上面提到的路由查表，属于业务处理时内存的限制；而进一步的加密解密DPI，则会对CPU和内存造成双重压力。这种情况下，CPU之外的加速器是必要的，用来缓解cycle和内存的压力。

    加速器自己整个FPGA当然啥都能搞定，但讨论这个价值不大。我是想看看看主流发货的CPU本身有没有内置的加速功能，比如AES-NI对加解密，GPU对模式匹配等等。如果可以用好，那么无需任何硬件开发一颗CPU能不能做到20-30G多业务路由器？如果可以，应该会有一些有趣的市场影响。不过有点遗憾的是目前Intel GPU暂时不支持通用计算，棒子的GPU思路只有等下一代ivybridge（那种外插两块高端独显的做法只有学术研究的意义，毫无商业价值）

68. 阿土仔 于 2011-11-11 11:12 下午

    芯片性能的提升基本还是按照摩尔定律来的，如果用户对于转发速度，特别是小包线速的提升需求小于X86芯片性能提升而带来的转发的提升情况的话，即使对于转发的提升小于摩尔定律，也一定是可以覆盖的。目前来看，这样的场景肯定不在少数。

69. 理客 于 2011-11-12 3:36 上午

    如何充分利用以摩尔定律高速增长的通用CPU和GPU做IP报文处理，包括IP/MPLS转发、查表、TM、IPSEC、DPI、firewall、GGSN/SAE GW等等，对传统路由器经典架构的改造，确实是一个很好的方向，虽然具体实现上还很难在很短时间内商用，但是非常值得研究的方向，前面有湾友说了C的研究，不知道J/A/H投入了怎样的研究。
    路由器早期用的就是通用CPU，但因为internet发展导致的IP网络发展的速度远超过了CPU处理IP能力的速度，导致很快在中端甚至低端里靠近中端的部分的路由器都放弃了CPU转发，其中就有发大的NS，但之后因为PC在进入服务器并开始统治服务器市场让专用服务器芯片比如alpha/sparc等不得不黯然退场后，以及internet 2.0带来的大发展，使通用CPU/GPU得到了高速发展，解决了计算能力和IO能力，从而再次接近了路由器专用芯片的处理能力，这势必对当前主流路器设计产生影响，虽然很短时间内还不好有定论，但只要路由器在100G的主流市场阶段要停留5年，那么CPU/GPU的机会是一定的。路由器再次轮回到CPU带上GPU，是可能的，intel自身有能力做任何事，但IP用的NP/多核的市场对intel太小了，在面临AMD技术上的几次大威胁后，intel还是放弃支流，倾力投入在X86 CPU上，从而导致X86 CPU顺带GPU的爆发，这是所有其他厂商加在一起都难以抵挡的，本无意栽柳，却反过来真的影响到了目前主流路由器的架构，有心插花花不活，无意栽柳柳成荫，看来宏志大师的法轮大法很高啊:)
    intel成功占领服务器市场，而Windows却还在PC折腾，主流的mobile和server还是最佳配角，高下可分。mobile和server根上都是UNIX/LINUX，如果gates还掌舵MS，不知道会不会能有奇迹？MS这些年，真的是不老廉颇难回天，MS再无爆发的话，估计也就到头了。

70. 理客 于 2011-11-12 3:38 上午

    如何充分利用以摩尔定律高速增长的通用CPU和GPU做IP报文处理，包括IP/MPLS转发、查表、TM、IPSEC、DPI、firewall、GGSN/SAE GW等等，对传统路由器经典架构的改造，确实是一个很好的方向，虽然具体实现上还很难在很短时间内商用，但是非常值得研究的方向，前面有湾友说了C的研究，不知道J/A/H投入了怎样的研究。
    路由器早期用的就是通用CPU，但因为internet发展导致的IP网络发展的速度远超过了CPU处理IP能力的速度，导致很快在中端甚至低端里靠近中端的部分的路由器都放弃了CPU转发，其中就有发大的NS，但之后因为PC在进入服务器并开始统治服务器市场让专用服务器芯片比如alpha/sparc等不得不黯然退场后，以及internet 2.0带来的大发展，使通用CPU/GPU得到了高速发展，解决了计算能力和IO能力，从而再次接近了路由器专用芯片的处理能力，这势必对当前主流路器设计产生影响，虽然很短时间内还不好有定论，但只要路由器在100G的主流市场阶段要停留5年，那么CPU/GPU的机会是一定的。路由器再次轮回到CPU带上GPU，是可能的，intel自身有能力做任何事，但IP用的NP/多核的市场对intel太小了，在面临AMD技术上的几次大威胁后，intel还是放弃支流，倾力投入在X86 CPU上，从而导致X86 CPU顺带GPU的爆发，这是所有其他厂商加在一起都难以抵挡的，本无意栽柳，却反过来真的影响到了目前主流路由器的架构，有心插花花不活，无意栽柳柳成荫，看来宏志大师的轮子法力很大啊:)
    intel成功占领服务器市场，虽然失了mobile市场，而Windows主要还在PC折腾，主流的mobile和server还是最佳配角，高下可分。mobile和server根上都是UNIX/LINUX，如果gates还掌舵MS，不知道会不会能有奇迹？MS这些年，真的是不老廉颇难回天，MS再无爆发的话，估计也就到头了。

71. 根本不相干 于 2011-11-12 5:05 上午

    但只要路由器在100G的主流市场阶段要停留5年，

    intel还是放弃支流，倾力投入在X86 CPU上…有心插花花不活，无意栽柳柳成荫，

    ———————–

    这两点也正是我所关注的核心之所在。Intel如果嵌入部门来说我们为通信设备定制一款多好多好的CPU，我会毫不犹豫说那凉快那呆着。要享受的是它每年主流部门占据的最大块研发资源，而不是内部边缘部门的所谓业务拓展

72. multithreaded 于 2011-11-13 6:11 下午

    〉其实上面的讨论基本明确了我的判断：这一代SNB在40G级别以下IO裸奔不是瓶颈，相反业务处理构成瓶颈。

    我认为IO恰恰是瓶颈口，谁有能力掌握了40G的IO处理能力，谁就可以开会大笑了 ：-）

    任何小看82599类似driver的人可能都会在这拌一下:-)(比如82599的手册有800多页，有多少人能把它读一遍？)

    业务相对来说办法会多一点，比如可以利用GPU.

73. 根本不相干 于 2011-11-13 6:18 下午

    multithreaded，能否具体说明下IO瓶颈在哪里？

    1) PCI-E
    2) 内存
    3）NIC driver对硬件的操作，hacking的难度

    如果是前两个，那么这个瓶颈是硬的，受限于物理环境。如果是第三个，那就是软瓶颈，受限于专业技能。能否告知你的主要担心是在那个层面？

74. 胡不才 于 2011-11-13 7:16 下午

    看看这里的介绍，http://en.wikipedia.org/wiki/IEEE_802.3
    不才列了下面的日期，前面是spec的日期，后面是走向主流的时间，如果我们暂时放弃到底是用NP或者CPU/GPU，谁能告诉我，未来到底是什么？100G要跑什么样的服务？大宋何以占领技术的制高点？

    1990 10MBASE-T SPEC 1995-2000 popular
    1995 100MBASE-T SPEC 2000-2005 popular
    1999 1GBASE-T SPEC 2005-2010 popular
    2006 10GBASE-T SPEC 2010-2015 popular
    2010 40G/100G SPEC 2015-2020 popular
    2015 4-lane 100G SPEC 2020-2025 popular

    。。。

75. multithreaded 于 2011-11-13 9:20 下午

    to#73:

    1. 楼上#46已经回答了你的第一问, i.e., it is impossible to have 40Gbps based on PCIe 2.0. SNB will have PCI-e 2.0 and therefore it cannot process packets at 40Gbps.

    2. Memory is an issue but if you can manage the cache coherence protocol, it is possible for you to ride over it.

    3. Hacking linux driver for high-performace is the art and I am not sure how many people can do this type of work. You really need to find two people at least, one knows the Linux kernel and the other knows system-level programming.

    Maybe you can start to read 800+ pages of Intel 82599 manual, then you will understand what I am talkling about.

76. Panabit 于 2011-11-13 10:20 下午

    问一下，你们口中的40G是指单向还是双向？

77. 根本不相干 于 2011-11-13 10:37 下午

    for the #46 reply, it has made a interesting premise that, only 1 X8 interface could be used, but it’s totally unreasonable, for 2 x8 interface mainboard is very common today. I don’t know why making such a statement as your grounds.

    For the memory, Quad-Channel DDR3 1333 is common for $300 SNB, means 40GB/s bandwidth; while 40Gb/s forwarding will need 40*4=160Gb/s = 20GB(DMA in/out, CPU in/out, not considering advanced feature like Direct Cache Access of Intel IOAT). so 50% of memory bandwidth effiency can still work, not very difficult.

    I think detailed discussion including quantitative analysis is more meaningful, without any first impressions

78. 根本不相干 于 2011-11-13 11:01 下午

    我想探讨的是40G forwarding （40G in and 40G out），端口速率是40G(2*20G, 2个82599 chips)

    CPU假定以SNB E5 1620为标的讨论吧，要不太分散。把一套16lane在BIOS配成X8+X8，接两块82599 NIC，内存配4通道1333，能否搞定40Gb forwarding裸奔？

79. 根本不相干 于 2011-11-13 11:03 下午

    不好意思我对单向和双向这个说法有点憎恶：）不知道上面能否解释清楚大家讨论的背景？

80. Panabit 于 2011-11-13 11:04 下午

    我改天再E3 1275 + C206上看看能到多少。小包肯定没戏，大包可以看看。

81. 根本不相干 于 2011-11-13 11:56 下午

    E3 1275太悬了，双通道1333，内存撑不住。除非能达到100%的内存带宽效率，或者有其它类零拷贝方法可以免除大包payload进CPU。另外Panabit网卡不是接在C206上吧？那样PCH本身可能成为瓶颈，目前服务器高速NIC接口都是直接接CPU的，SNB直接出的PCIE LANE已经太丰富了，PCH仅仅用于兼容传统低俗外设。

    最合适的是E5 1620，对应的桌面版是i7 3820，价格都是$294，四通道内存，可惜刚刚发布还没量产，不知道能不能拿到样品测试。如果要拿已发布的产品，只有上一代westmere，不过它的三通道1333产品太贵，技术上即使测完也不会产生太大震撼，还不如测它的主流desktop像i3 530，看能不能到20Gbps(价钱只有100刀出头，双通道1333，可当半个E5 1620用)

    所以建议Panabit要测的话，不妨多等几天等1620货3820量产，最好有啥厂商推广新平台拿样品给你帮他们测，那是最好不过了：）

    棒子的研究对启发思路开了个好头，但是用上千刀的高端型号去堆性能，没有继续下去的价值。那个东西搭出来要7000刀，做出50-60G又有何意义？对产业无法造成震动。关键是主流的不超过300刀的X86(全部加完不超过1万人民币)系统能干啥才有意义。

82. Panabit 于 2011-11-14 12:32 上午

    C206的网卡是从CPU的X16上分出来的，不是从桥片上弄出来的。

83. multithreaded 于 2011-11-14 12:37 上午

    To #77:

    We assume using a 1U server on the market in which only one Intel 82599 NIC can be used. This configuration can support 20Gbps even for small packets since we have developed such a system for some L4-L7 applications.

    If you use a specially designed motherboard or a 4-port 82599 NIC with x16 PCI-e lanes, that would be a different story since no one knows its performance.

    Anyhow my point is if one can handle IO, he/she will have no issues to handle user-space applications.

84. 根本不相干 于 2011-11-14 1:11 上午

    Yes single 82599 NIC is also a good idea for 20Gbps workload in production environment, with dual channel memroy, and entry-level mainstream CPU below $200, like 20w E3 1220L or some i3 processor.

    The reason that I metioned 40Gbs, is just my interest in the capability of Intel’s performance mainstream seires $300 CPU with Triple and Quad Channel DDR3 support:)

85. X86勾引了我 于 2011-11-14 2:29 上午

    大家都在讨论Intel的CPU,我有个疑问，难道AMD的CPU有那么差劲吗？（没人提）
    新出的推土机架构的Opteron如何？

86. sailing 于 2011-11-14 6:58 下午

    网上正在传言Apple有收购AMD的可能，很遗憾Jobs没有再多活几年。如果可能，Apple花$10B把工艺问题解决掉，让AMD的Die和Intel的一样宽敞。剩余的在体系结构上的东西，AMD的努力很值得尊敬。

    Bulldozer已经有了评测数据，不便评论，自己也可以测。

    大家是讨论40G的时候，最好说明是1×40Ge还是4×10Ge。

    还有如果就是“SNB+网卡”这种方案很难在Networking Infrastructure产品级别上直接使用。

    我见过更多的设计都是SNB+PCIe 2.0+多个×4 PCIe Lane的FPGA方案。
    SNB有40个Lane，刨除IOH使用的，剩余的可以组成4个×8的，不过我没有见到用齐的，有很多在实际产品中出现的制约因素，一言难尽。

87. huhu 于 2011-11-15 1:43 上午

    这个在去年的sigcomm上发表，用gpu实现是一个很好的研究方向。最大的可能是取代企业级路由器。

88. kevint 于 2011-11-15 1:24 下午

    GPU的pipeline模型天生就是给图形做的，通用编程并不容易。 我不认为除了图形领域及少部分计算领域外GPU能有任何建树

89. multithreaded 于 2011-11-15 5:50 下午

    所以这还是一个超前的研究领域，还没有人能在商业上做成功过。

    不过它给人带来的联想是无限的：-）

    Stay Hangery and stay follish

90. 大宋民工 于 2011-11-15 6:11 下午

    哥不懂技术，哥敢下结论棒子一定是在忽悠。

    原因非常简单，因为这个东东对于棒棒来说几乎没有经济价值。

91. 沙加 于 2011-11-15 7:48 下午

    别太武断了。技术上的东西、商业上的价值还是要敢想