“《给力吧，x86》专题连载九：英特尔Sandy Bridge平台网络通信性能测试分析”有57个回复

1. TJ 于 2011-12-14 6:33 下午

   难道是用了DPDK?标准LINUX不可能达到20Gbps的小包吧

2. 根本不相干 于 2011-12-14 7:09 下午

   一直在关注你们对X86用于通信所作的努力，感谢老韩！

   这个测试也印证了我最近对SNB线速64B/20G可行性的猜想。对于文章结尾提到的E系列服务器平台，我推荐关注1620(尚未上市)和1220L。

   E5-1620价位比2600稍低不到300刀，却支持ECC,LLC也到了10M，缺省主频也提高到了3.6，然后最重要的还是支持四通道DDR和PCIE3（这两个东西简直是做通信杀人放火的必备武器啊，非常期待40G测试又能给我们树立怎样新的标杆）!!!不过缺点是主板socket不兼容1155，是2011的，而且功耗有些高，不过由于是单路方案尚可忍受

   至于E3-1220L，作为低功耗(20w)、低成本($189)方案，由于直接兼容2600一样的1155槽位，也很希望能立刻看到只有两核的它在20G/40G下的表现，也再次印证CPU的瓶颈在什么位置

3. 新手 于 2011-12-14 9:25 下午

   是否方便透露一下，在测试过程中，两个vCPU和三个vCPU场景下，NCPBench是怎么配置82599的吗？——比如设置几个TX/RX/RSS队列，如何设置cpu affinity的，等等

4. NGAF+ 于 2011-12-15 12:06 上午

   Linux原始的报文流程+协议栈,即使把RSS\中断负载均衡都用上,和上面的测试结果也有较大差距

5. george 于 2011-12-15 1:01 上午

   to 4，要大幅提升性能，这些小打小闹是不行的。Panabit的做法也不算独创，但是确实比较深入。要多思考，我导师跟我说的。

6. Panabit 于 2011-12-15 1:06 上午

   其实没有什么诀窍，一切诀窍均在于细节和专注！耐下心来，就那么几千行程序，1天50行，也就几个月的事情。

7. 根本不相干 于 2011-12-15 5:05 下午

   Panabit说得没错，需要像艺术品那样精雕细琢。大公司很难做出这样的事情，大家以完成KPI了事，代码堆砌而已。

   从测试结果看，NCPBench简单转发模式应该用了零拷贝。否则，双通道1333只有20GB带宽，而40Gb则需要两进两出40*4/8=20GB，已经是内存的理论带宽了，没损耗是不可能的。

   如果做业务，意味着要对包头进行分析，CPU必须要读进去内容，不知道这时是否要对82599做一些hacking，并利用Intel IOAT，比如设置header split，对header做DCA操作，硬件辅助一些stateless操作如checksum检测计算等。

8. 新手 于 2011-12-15 5:32 下午

   请问header split对性能的收益主要体现在什么方面？如果要做7层内容检测（不仅仅看header)的话，split还有没有优势？
   split会把报文分解为不连续的内存区域，在一定程度上加大了编程的复杂度（当然也不是不能处理）

9. 根本不相干 于 2011-12-15 6:00 下午

   对7层业务，不是每种业务的每一个包的payload都需要处理。那样的话，就没有所谓fastpath和slowpath了。在一个应用流的前面部分被识别后，后面的报文可以走fastpath，这时候header split就会体现出价值

10. 新手 于 2011-12-15 9:27 下午

    多谢指教!

11. 局外人 于 2011-12-16 8:25 上午

    sandybridge的io能力不错，但我认为还可提高，还有未调好的地方

12. 观众 于 2011-12-16 8:51 上午

    cache，cache是性能的关键

13. Panabit 于 2011-12-16 8:48 下午

    回11楼：的确是这样，还有优化的余地。

14. multithread 于 2011-12-18 12:21 上午

    To #7-#10:

    Intel已宣布不建议在82599上使用header split，它会触发一个hw的BUG.

15. 胡不才 于 2011-12-18 10:20 上午

    给一个Sun/Arista的Andy关于10Gbe的文章，文中提到了Intel收购了Fulcrum Microsystems，10年（2001-2011）来，Intel的CPU性能提高了100倍但大多数的网卡还是1G。一个Arista单chip的switch和思科6509的比较，同样的吞吐量，Arista用1U的空间和125W而思科用了15U和5000W。
    http://www.aristanetworks.com/en/blogs/?p=551

    我没有权限，但从现象看，Arista的EOS应该是基于X86的：http://eos.aristanetworks.com/2011/11/running-eos-in-a-vm/

16. 胡不才 于 2011-12-18 11:02 上午

    confirmed, it is x86 http://eos.aristanetworks.com/wiki/index.php/What_is_the_EOS_naming_convention%3F

17. Panabit 于 2011-12-19 10:24 下午

    NCPBench的结果肯定不是X86的最好性能结果，相信还有提高的地方。NCPBench只是给大家抛砖引玉，向大家说明，X86目前至少是能达到这样的性能的。另外，目前国内有好几个团队具备这样的性能能力，只是它们“可能”还没有形成自己的体系，还是依赖于操作系统内核。

18. kevint 于 2011-12-20 12:43 上午

    @14
    can you show the link of the bug?

19. 老韩 于 2011-12-20 2:42 上午

    目前正在接触一些国内团队，商讨本专题后续内容的合作可能性。也欢迎与我交流，邮件是hanxu0514 艾特 gmail。com

20. dotslash 于 2011-12-20 8:06 上午

    对在X86上用户空间转发性能做到足够高，可以看看这个成熟的开源实现: http://info.iet.unipi.it/~luigi/netmap/
    1.2G的CPU中的一个单核可以做到14.88Mpps的线速报文生成，并且可以做到10.66Mpps的简单转发；换言之，如果有三个流，被网卡RSS分配到3个core上，完全是可以达到31Mpps的转发能力的。

21. fhdjs 于 2011-12-25 8:03 下午

    呵呵

22. nslookupcn 于 2011-12-26 2:11 上午

    至Panabit，麻烦问题一下，NCPBench 0.8是内部测试工具嘛，可以提供下载嘛，期待中~

23. kevint 于 2011-12-26 5:38 下午

    @20

    1. 1.3G CPU是报文生成。不是报文转发。

    2.你的换言之是不成立的。

    一个core能达到10.6mpps是因为这哥们占用了所有LLC及membw。多core竞争的情况性能下降是很明显的。

24. dotslash 于 2011-12-26 8:52 下午

    @23

    Intel CPU在多核调度时cache的实际表现如何没有深入研究过，但Cavium这样的CPU里面，packet i/o 直接进cache，如果不查大的外部表，memory带宽对数据流没有任何影响；而对于报文而言，貌似每单个报文对cache的消耗可以忽略不计吧。即使在有外部表的情况下，prefetch机制也可以把对memory带宽的消耗减到最小，所以其性能scale up的能力很强，至少在8-10个核以内，实际程序中看到的资源竞争，一是来源于软件临界区的锁等待，二是来源于报文保序（对于单流而言，硬件保序此时成为了瓶颈，要是多流反而不存在问题），而看不到太大的非软件实现类的瓶颈（即你说的带宽瓶颈）。

    intel没有花心思去做报文的硬件保序调度，所以发明了个RSS来解决同一流调度到同一核的东东来实现伪scalability，至于这种伪scalability对LLC/memory利用效率的实际效果如何，我的确不应该拿C家上的效果往Intel上生搬硬套。当然，要是其实际效果有问题的话，倒可以从另一个侧面证明，X86做高性能网络处理，还是有致命缺陷的。

25. kevint 于 2011-12-26 9:52 下午

    恩。scalability的前提是大伙不竞争share的东西。如你所说，CVM和RMI在做芯片的时候已经替你操心过这些问题了。

    intel最大的好处和最大的坏处就是不用程序员操心cache。这哥们生为desktop/server，只是拿来做网络处理罢了

26. 阿土仔 于 2011-12-26 10:08 下午

    dotslash能详细解释一下为什么每单个报文对cache的消耗可以忽略不计及prefetch机制怎么把对memory带宽的消耗减到最小吗？最小是多小？谢谢

27. Panabit 于 2011-12-26 10:48 下午

    “prefetch机制也可以把对memory带宽的消耗减到最小”，这句话做和解释？我也想知道

28. 新手 于 2011-12-26 10:55 下午

    各位大佬，小弟对Cavium一无所知，请问硬件“报文保序”的确切含义是什么？
    A. 是纯2层的概念，跟任何flow无关
    整个系统呈现FIFO行为，先进入系统的报文一定先发出去
    比如报文按a/b/c/d顺序到达，一定按a/b/c/d的顺序进行转发，不关心a/b/c/d是否属于相同的flow（以及4层的序列号）
    B. 比A弱一些，多核情况下仅保证单核是FIFO行为，多核之间可以出现乱序
    比如报文按a/b/c/d的顺序到达，a/c分给core#0,b/d分给core#1，b/d可以在a/c之前离开系统
    C. 仅保证单个flow的满足FIFO模型，不关心flow之间的顺序
    比如报文按a1/a2/b2/b1的顺序到达，a1/a2属于flow#1，b2/b1属于flow#2，b2/b1可以在a1/a2之前离开，注意没有调整b2/b1的顺序
    D. 系统保证单个flow按照4层的序列号离开系统（非FIFO模型）
    这个是最常见的tcp流重组模型，不关心flow之间的顺序——但是对于udp而言，这个有意义吗？
    C和D的区别在于，对于单个flow，如果输入是乱序的，C保持乱序，D要纠正乱序

29. 阿土仔 于 2011-12-26 11:50 下午

    C

30. multithreaded 于 2011-12-27 1:32 上午

    #24,

    1. RSS is a Microsoft invention not Intel one. Please check it up.

    2. Since no prefetch can guess 100% right, I doubt one can ignore the cache miss rate when processing a packet.

31. 根本不相干 于 2011-12-27 3:29 上午

    在82599做Intel的DCA时，配合header split有个麻烦：不支持程序配置任意长度的”header”。最好的always方式，也要先自以为是判断一下它理解的所谓“header”，如果它判断出来了，就结束了，判断不出才会读取一定长度的认为是包头。这对于任意复杂封装的包头（比如各种隧道格式）不太合适，DCA能力发挥不好。

    当然，这不是IOAT架构问题，只是NIC实现问题。如果下一代NIC能做到程序定义什么是“header”，至少我可以自定义比如头128个byte是header，那就会好很多

32. matrix 于 2011-12-27 9:19 上午

    to 根本不相干,
    你要的DCA，首先要能够识别报文。”任意复杂封装的包头（比如各种隧道格式）”，如果只是ASIC方式的配置寄存器来识别提取，比较困难（特别是私有封装）。
    然后才能根据报文识别，控制每一个报文需要缓存报文头长度。

    这个玩意，XLP可以做到。它的前端微引擎（就是16个mips ucore，c代码编程），然后可以对每一个报文就行单独控制缓存报文头长度

33. Multithreaded 于 2011-12-27 2:57 下午

    http://info.iet.unipi.it/~luigi/netmap/

    I read their INFOCOMM’12 paper but find out the forwarding/switching rates are around 3-4Mpps, far from 14.88MPPS.

    It seems thet did NOT run any IPv4 routing algorithm. The real performance should be less than what they reported

    Last but not the least important they use only one core to do experiments, avoiding the hard issue of how to make good use of multi-cores???

34. 根本不相干 于 2011-12-27 5:01 下午

    to Matrix

    不是，不需要识别报文，它只需要把我配置好的给定字节数(比如128B)当成“header”送上去就行了。剩下的工作，交给软件。

35. 陶潜 于 2011-12-27 9:26 下午

    to 阿土仔:
    关于28/29楼，“仅保证单个flow的满足FIFO模型”，从实现的角度而言，是不是每个flow所有的报文去的一个固定的core?这样才能保序。

    这样的话，在进入选择进入哪一个核之前，应该有一个器件:从packet里识别出一个流(譬如五元组)，给报文tag一个flow id,然后再去不同的core进行处理。

    不知道我理解的对不对。
    多谢

36. 阿土仔 于 2011-12-28 1:24 上午

    “仅保证单个flow的满足FIFO模型”仅是必要条件，如果保证进入CPU的报文和出去的报文都是保序的，其实也满足了这个条件。因此一条流是否进同一个core，是不需要的。但是能够直接分发到不同的core是比较好的，这样core之间的影响会小。

37. 阿土仔 于 2011-12-28 1:26 上午

    832是64K虚拟流，就是你说的给报文tag一个flow id，但没有实际流那么多条

38. 陶潜 于 2011-12-28 7:43 上午

    to 36楼，一个流进入不同的core,还能做到保序，这个需要软件干预，还是纯粹硬件的功能？

39. Multithreaded 于 2011-12-28 12:45 下午

    一个流进入不同的cores是一个被证明的不好的选择，在实际中没有人会采取这种做法。

40. 阿土仔 于 2011-12-28 6:43 下午

    to 38:这个依赖于所用芯片的硬件保序设计，比如732没有硬件保序功能，那只能软件做

41. 陶潜 于 2011-12-28 9:26 下午

    to 39，40楼，谢谢。不同core之间对同一个流保序，如果是软件保序，能否提供一个伪代码片段描述？如果是硬件保序，能否提供一篇文章，描写电路如何实现？

42. 根本不相干 于 2011-12-28 10:33 下午

    关于X86做TM：
    其实，目前的网卡已经具备一些简单的辅助功能，比如82599支持128个queue，和8个优先级的packet buffers，可以完成一些基本的TM/shaping

    Descriptor Plane Arbiters and Schedulers:
    • Transmit Rate-Scheduler — Once a frame has been fetched out from a transmit rate-limited
    queue, the next time another frame could be fetched from that queue is regulated by the transmit
    rate-scheduler. In the meantime, the queue is considered as if it was empty (such as switched-off)
    for the subsequent arbitration layers.

    • VM Weighted Round Robin Arbiter — Descriptors are fetched out from queues attached to the
    same TC in a frame-by-frame weighted round-robin manner, while taking into account any rate
    limitation as previously described. Weights or credits allocated to each queue are configured via the
    RTTDT1C register. Bandwidth unused by one queue is reallocated to the other queues within the TC,
    proportionally to their relative bandwidth shares. TC bandwidth limitation is distributed across all
    the queues attached to the TC, proportionally to their relative bandwidth shares. Details on
    weighted round-robin arbiter between the queues can be found in Section 7.7.2.3. It is assumed
    traffic is dispatched across the queues attached to a same TC in a straightforward manner,
    according to the VF to which it belongs.
    • TC Weighted Strict Priority Arbiter — Descriptors are fetched out from queues attached to
    different TCs in a frame-by-frame weighted strict-priority manner. Bandwidth unused by one TC is
    reallocated to the others, proportionally to their relative bandwidth shares. Link bandwidth
    limitation is distributed across all the TCs, proportionally to their relative bandwidth shares. Details
    on weighted strict-priority arbiter between the TCs can be found at Section 7.7.2.3. It is assumed
    (each) driver dispatches traffic across the TCs according to the 802.1p User Priority field inserted by
    the operating system and according to a user priority-to-TC Tx mapping table.
    Packet Plane Arbiters:
    • TC Weighted Strict Priority Arbiter — Packets are fetched out from the different packet buffers
    in a frame-by-frame weighted strict-priority manner. Weights or credits allocated to each TC (such
    as to each packet buffer) are configured via RTTPT2C registers, with the same allocation done at
    the descriptor plane. Bandwidth unused by one TC and link bandwidth limitation is distributed over
    the TCs as in the descriptor plane. Details on weighted strict-priority arbiter between the TCs can
    be found in Section 7.7.2.3.
    • Priority Flow Control packets are inserted with strict priority over any other packets.
    • Manageability packets are inserted with strict priority over data packets from the same TC, with
    respect to the bandwidth allocated to the concerned TC. TCs that belong to manageability packets
    are controlled by MNGTXMAP.MAP.

43. Panabit 于 2011-12-28 11:56 下午

    楼上的，你说的这些特性，我估计Intel自己都没用过

44. 根本不相干 于 2011-12-29 1:08 上午

    这8个TC是为DCB做的，应该还是有一定应用空间的

    不过Intel没用过很正常。我记得当初做产品开发时，测试人员比开发人员对设备熟多了，N多花样开发人员自己都不知道还可以这么玩：）

45. ATOM 于 2011-12-29 10:10 下午

    http://tech.sina.com.cn/it/2011-12-30/08396585208.shtml
    英特尔承认上网本销量下滑 寄望于新兴市场
    intel 不会停了现在的ATOM把

46. 小韩 于 2011-12-30 8:53 下午

    ATOM不可能停的，ATOM应该是Intel未来一段时间在嵌入式领域的主打产品，昨天刚有新闻稿说又交付了一批新型号开卖。

47. ATOM 于 2012-01-03 8:29 下午

    老的型号，新的型号好像都要SOC了，更加适合平板，手机，是否可以提供大量PCIE或者网络能力呢？ 不知道INTEL是否会把面向手机，平板的芯片做的能够非常适合网络用。 如果新的ATOM出来了，老型号量就会大量被取代，不停产，估计价格也不会再这样好了把。

48. ATOM 于 2012-01-05 9:14 下午

    英特尔在第二季度彻底停产前，将减速生产酷睿i5-661/660、酷睿i3-530、奔腾E5700和赛扬E3500处理器。

    此外英特尔应该也会在2012年第二季度停止生产酷睿i7-960/950/930/870/880S/870S、酷睿Core i5-2300/680/670、酷睿E7500/E7600、奔腾G960、E6600/E550以及赛扬E3300处理器。而酷睿i7-875K/860S、酷睿i5-760/750S/655K和赛扬450/430处理器在第一季度就会停产。

49. 根本不相干 于 2012-01-07 12:25 上午

    Intel和6wind有一个测试数据，含L3转发（但没给出路由表数，估计不大最多几万条，至少应该都能命中LLC,否则感觉不太可能)

    怎么贴PDF文件？想贴出来供大家参考一下

    基本数据是：

    E5600每个核14-18M pps，单路3个核达到饱和42M pps（估计受限于内存和IOH)，

    E5600双路6个核达到饱和84M pps（应该是内存和IOH翻倍了)；

    sandy bridge E5每核心转发性能差不多，单路6个核达到饱和86M pps（果然SNB的内存四通道和IO能力远超前辈)

50. 小韩 于 2012-01-07 12:32 上午

    貌似做NPC没人用4通道，4通道只有高端发烧友用得上。对于带上安全业务的软件系统来说，4通道的意义也不大。

51. 根本不相干 于 2012-01-07 12:58 上午

    4通道已经出现在很多200-400美元的CPU上，本身价格已经不是问题。

    但是，8核心CPU是否适合做NPC，确实需要探讨。8核心主频上不去，价格也贵。

    目前的工艺来看，4核心是性价比不错的主流选择，而此时对应的2通道或3通道应该也能满足要求。

52. sdwfww725 于 2012-01-11 12:02 上午

    看了好了，大家都在讨论软件方面的问题，不敢发言，一直在做X86平台的网络安全的主板的硬件方面，看着x86系统性能的逐步提升，从当年的815系列，到后来的845 865 945 7520 965 G41 一直到现在的Q67(Sandy Bridge)系列，与之搭配的网卡性能也逐步提高，到现在能在64k的小包下能达到线速，感觉intel在这方面还是不错的，大家都在谈论软件的，是否可以讨论一下硬件方面的东西，比如说系统的搭配，哪种硬件的扩展方式更适合客户使用，平台搭配何种的网卡能更好的发挥性能，请大家不吝赐教

53. 胡不才 于 2012-02-14 11:51 上午

    how about this:

    Intel’s next-generation communications platform, Crystal Forest, is expected to deliver up to 160 million packets per second performance for Layer 3 packet forwarding, making it possible to send thousands of high-definition videos across each network node. Previously, only ASIC or specialized processors were capable of sending more than 100 million packets per second. The Intel (R) Data Plane Development Kit, a set of software libraries and algorithms, improves the performance and throughput of packets on Intel architecture platforms to yield more than five times the performance over previous generations of Intel platforms.

    http://newsroom.intel.com/community/intel_newsroom/blog/2012/02/14/intels-next-generation-communications-platform-key-to-accelerated-network-services

54. hid 于 2012-02-15 9:40 下午

    使用风河Wind River提供的Crystal Forest平台的模拟模型加快下一代通讯平台的软件开发、测试和集成

    英特尔已经披露了代号为“Crystal Forest”的下一代通讯平台的一些重要功能。这个通讯平台是建立在英特尔在通讯基础设施领域的强大的基础之上的，将更有效率和更安全地管理整个网络的数据处理，同时，满足处理云连接和内容处理的特殊需求。

    英特尔称，一天中的每一分钟整个网络将上载30个小时的视频。到2015年，每一秒钟向IP网络上载的视频大约需要5年时间才能看完。随着这个数字的继续增长，这个负担将落在设备厂商和服务提供商的身上。他们要提供一个解决方案以节省成本的方式管理日益增长的通讯量，同时不影响性能和安全性。

    　　采用英特尔的“Crystal Forest”通讯平台，设备厂商将能够把三个通讯工作量（应用、控制和数据包处理）整合到多核英特尔架构处理器以提供更好的性能和加快产品推向市场的时间。厂商还可以根据多个英特尔处理器的选择开发一种具有伸缩能力的产品，为将来提高性能做好规划。

    　　英特尔下一代通讯平台Crystal Forest能够为3层数据包发送提供每秒最多1.6亿个数据包的性能。，使它能够在每个网络节点发送数千个高清视频。以前，只有ASIC（专用集成电路）或者专用处理器能够每秒钟发送1亿个以上的数据包。英特尔数据平台开发套件（Data Plane Development Kit）是一套软件库和算法，改善了英特尔架构平台上的数据包的性能和吞吐量，比上一代英特尔平台性能提高了五倍。

    　　英特尔Crystal Forest平台将让设备厂商设计出更灵活的平台，包括从小型和中型企业防火墙到高端路由器等多种设备。

    　　开发者能够使用英特尔全资子公司风河(Wind River)提供的Crystal Forest平台的模拟模型加快软件的开发、测试和集成。

55. hid 于 2012-02-15 10:01 下午

    http://news.mydrivers.com/1/217/217805.htm

56. 小猎 于 2012-03-12 5:14 上午

    最新猎头职位：京深：攻防研究（渗透 漏洞挖掘）/架构（产品线 通用网络平台）/系统工程师/测试/LinuxC/java工程师/大客户销售（金融）、深圳：市场技术总监/产品运营经理/金融售前产品经理/区域销售总监（广州、深圳、福建、海南、江苏、西北）、成都：VPN研发 联系qq：2594873804

57. 凌动 于 2012-10-15 12:37 上午

    看完了x86平台的所有测试专题，有个疑问就是在各种测试场景下的CPU占用率是怎么样的？好像一篇都没有提到这一点，是否所有的测试条件下CPU的计算能力都不是瓶颈？