给力吧，x86（2）——12月13日测试记录

作者 | 2010-12-20 19:36 | 类型 互联网, 网络安全, 通讯产品 | 176条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列内容：

1个月前的测试让人见识了Panabit这一年来的进步，也看到了x86平台在通信领域的潜力。不过，上次的测试并不细致，1个N270平台也不能代表一切，所以我和Panabit团队达成一致，在接下来的一段时间内以细水长流的形式保持一系列测试合作。

为了让测试不那么无聊，我打算时不时地换种形式娱乐一下。比如这次的测试就是一道问答题，我提出了一个性能目标——2个千兆口64Byte裸奔线速，看看PanaOS用什么档次的平台能够达到。插一句，我从来不觉得裸奔没意义，相反认为意义重大，因为转发能力是一切的基础。并且曾经听几个国内安全厂商的朋友说过，他们做产品规划的时候都用这个小包裸奔2G的数字作为千兆低端和千兆中端的分界线。

看看Panabit团队拿了一台什么样的设备来应战：汇尔（HOLL）科技IEC-516P，Atom D525/1G RAM/i82574L x 6，一台看起来很实用的1U Box。从PCB上看，应该可以有两组硬件Bypass，还有3个SATA和一个PCIe 1x接口。Atom，难道这次又用它来挑战IT人的传统认识？不费脑子了，先测了再说。

测试项·配置帧长度 2个GE做1组桥（100%=2Gbps） 6个GE做3组桥（100%=6Gbps）
吞吐 平均延迟 吞吐 平均延迟
64 Byte 42.87% 19 us 34.96% 65 us
128 Byte 53.25% 18 us 43.76% 1440 us
256 Byte 67.65% 20 us 53.91% 1807 us
512 Byte 82.36% 37 us 59.76% 3514 us
1024 Byte 93.23% 73 us 59.23% 585 us
1280 Byte 96.00% 60 us 59.71% 112 us
1518 Byte 100% 64 us 61.18% 197 us

测试结果里隐藏了太多的玄机，比如2个GE做一组桥的时候，D525平台下的性能怎会和上次的N270基本一样？比如6个GE做3组桥的时候，平均延迟作何解释？再比如，多路桥的大包测试结果和N270基本一致，瓶颈又出在哪？

不过，和整机64Byte吞吐量2.1Gbps（3.12Mpps）的结果相比，一切都是浮云了。一个在x86工控机中价格优势最明显的BOX，裸奔出这样的性能，还真是头回得见。立志进入嵌入式领域的英特尔应该注意了，在Wind River Network Acceleration Platform还没有成功案例之前，PanaOS也许是x86平台上性价比最高的选择，是不是考虑给Panabit提供些特别支持呢？

从我们的角度看，Panabit自诞生以来一直保持着技术和模式上的双重创新，得到市场认可并成功地活了下来，对整个行业都有着重大的意义。说颠覆还太早，但它确实已经成为国内通信安全圈中不容忽视的新兴力量，有着相当不错的发展前景。基于此，我们团队一致决定授予Panabit 计算机世界2010年年度创新奖。

(8个打分， 平均：3.50 / 5)

工具箱
本文链接 | | 打印此页 | 176条用户评论 »

雁过留声

“给力吧，x86（2）——12月13日测试记录”有176个回复

  1. 给力吧，x86（1）——11月10日Panabit测试记录 : 弯曲评论 于 2010-12-20 7:28 上午

    [...] 2 12月13日Panabit测试记录（Atom D525） [...]

  2. Panabit 于 2010-12-20 8:17 下午

    我们后续将会以细水长流的方式：

    1）对现有不同芯片组的IPC平台做一个综合评估，比如芯片组整体网络IO吞吐能力，单槽吞吐能力以及和CPU Core的扩展关系；

    2）对现有不同型号的网卡的吞吐量和小包transaction速率做评估，比如82573/82574, 82571, 82575, 82576, 82580, 82598, 82599等。

    我做这个事情的目的不是为了宣传什么（不相信的人可以略过），主要就是为了展现一下最贴近X86硬件性能的一面，在这个过程中，我们也希望自己能不断的进步。也希望这些测试和评估能给其它的兄弟厂商提供一些参考。

  3. Panabit 于 2010-12-20 8:23 下午

    希望各个IPC厂家来给我们提供支持，呵呵。

  4. 路上 于 2010-12-20 9:51 下午

    毛工的技术水准 有提高了一大步了

    慢慢来 毛公

    特此过来围观 纯支持下

  5. Paul Huang 于 2010-12-20 11:22 下午

    毛生加油！

  6. 大脸猫 于 2010-12-20 11:28 下午

    自娱自乐

  7. Panabit 于 2010-12-20 11:40 下午

    呵呵，先自我乐，然后再让大家乐，不亦乐乎？

  8. Panabit 于 2010-12-20 11:40 下午

    多谢Paul!

  9. Will Chie 于 2010-12-20 11:54 下午

    很强大的说，首席弟子实力不容小觑

  10. 老韩 于 2010-12-21 12:18 上午

    要的就是自娱自乐，自己都没乐，怎么能指望大家同乐呢:)

  11. 加菲猫 于 2010-12-21 4:10 上午

    2）对现有不同型号的网卡的吞吐量和小包transaction速率做评估，比如82573/82574, 82571, 82575, 82576, 82580, 82598, 82599等。

    期待ing. 特别是后面两个:82598/9~

  12. Panabit 于 2010-12-21 4:27 上午

    请静待一下，呵呵，春节前我们先将一些软件山的准备工作做好。

  13. liang 于 2010-12-21 6:26 上午

    裸奔!!!,no freebsd?

  14. Panabit 于 2010-12-21 6:29 上午

    裸奔的含义就是不跑Panabit业务引擎，相当于一个纯桥。

  15. Will Chie 于 2010-12-21 6:52 上午

    to Panabit，
    求教，什么是软件山？

  16. Panabit 于 2010-12-21 6:53 上午

    Sorry, 那个是笔误，应该是“软件上”，:)

  17. liang 于 2010-12-21 7:46 上午

    跑到线速的瓶颈在那里?主频?内存访问延迟?
    毛公赐教

  18. 加菲猫 于 2010-12-21 5:00 下午

    — 跑到线速的瓶颈在那里?主频?内存访问延迟?

    个人感觉在网卡收发的工作机制上, pcie带宽是充裕的, 如果是裸奔, 数据包基本上是在高速缓存上被转发的, 故内存带宽也不存在问题.

    不知这样考虑对不对?

  19. Panabit 于 2010-12-21 5:51 下午

    从带宽角度而言，内存并不存在瓶颈，主要还是和网卡有关。

  20. liang 于 2010-12-21 5:54 下午

    panabit:裸奔的含义就是不跑Panabit业务引擎，相当于一个纯桥。

    如果问题在网卡收发的工作机制上,是驱动的问题,还是协议栈?
    提高主频,或降低主频会有多少影响

  21. Panabit 于 2010-12-21 6:32 下午

    是整个系统架构的问题，CPU在任何时候，都不应该是瓶颈，所以和主频关系不大。

  22. 阿土仔 于 2010-12-21 6:46 下午

    如果裸奔，和panaos有什么关系呢？

  23. 老韩 于 2010-12-21 7:08 下午

    驱动和协议栈都在PanaOS进程里，只不过数据流不再走DPI了。

  24. 阿土仔 于 2010-12-21 11:15 下午

    裸奔都走了什么流程呢？查流表吗？报文解析吗？等等。。

  25. gaohl 于 2010-12-22 4:07 上午

    D525千兆小包跑到43%，请问是多核跑起来了呗？

  26. Panabit 于 2010-12-22 4:19 上午

    物理上还是只用了一个Core。

  27. 理客 于 2010-12-22 5:00 上午

    此类性能优化，一般先裸奔，就是什么都不做，收到就发出去，从而得到系统最大的performance，以此为基准，增加业务，一步一步优化，就比较容易知道瓶颈在哪，应该在哪下功夫。为了更容易监控和发现性能瓶颈，我想PANAOS应该有一套内嵌的监控系统，在增加新的业务功能时，通过此系统检测性能瓶颈，以免每次都要手动的做很多重复工作

  28. Panabit 于 2010-12-22 5:09 上午

    理客，你一说就到点子上了，呵呵。我们是这样想的，先解决裸奔时候的性能问题（这个不光可以解决性能问题，还可以用来评估硬件），然后通过一步一步增加功能，来评估由于额外访问内存对性能的影响。性能评估和优化的前提就是要有一个基准系统对比，裸奔时候的结果可以从某种程度上看着基准性能。

  29. Panabit 于 2010-12-22 6:23 上午

    狗日的百度，在我们决绝他们的推广要求后，又屏蔽我们了。

  30. MIPS 于 2010-12-22 6:50 上午

    INTEL又何尝不是这样呢，这就是垄断的力量，Panabit在不断推广INTEL的时候其实，也在利用他们的垄断力量。

  31. roccen 于 2010-12-22 8:16 上午

    请教Panabit/老韩二个问题:

    1、双接口吞吐达到42.87%极限的时候，CPU占用率达到多少？单接口进再环回出去的吞吐量，或者A接口进B接口出的单向流量可否达到100%？

    在下最近恰也正在研究Linux下用户态直接收发包效率的改进问题，发现用类似本文裸奔的方式来测试整机性能时，Linux NAPI polling+中断的调度机制可以让多队列并发收包效率提到足够高，但始终无法让单队列的收包速率达到(1.5Mpps)线速。不知FreeBSD下的纯polling能否做到这一点？

    2、裸奔测试的话，在内存带宽没有瓶颈的情况下（1-2个Gbps应该没有什么内存瓶颈吧）,NIC ring buffer的填充速率是性能的最重要因素，即吞吐率和pps接近正比，那么，为什么64B时都可以做到43%，而128B时才仅仅增加了10%？ 是否整个裸奔处理路径上存在内存拷贝或者全报文范围内的随机内存访问？

  32. Panabit 于 2010-12-22 8:41 上午

    回楼上：
    1）不可能100%，这是由网卡决定的，82574的吞吐率（或者说TRANSACTION速率）没法做到64bytes线速，目前做到线速，只有82571,82575,82576,82580可以做到；
    2）64B和128B不成比例增加的问题，在所有的X86平台上都存在，我也没搞明白是什么原因，真希望找个Intel的大拿问问。

  33. liang 于 2010-12-22 5:53 下午

    linux什么都不优化，默认情况下裸奔也只有20%不到

  34. 天外有天 于 2010-12-22 6:12 下午

    软件在内核态还是用户态？

    没有使用linux的协议栈吧，
    直接从网卡收发包，自己跑的协议栈？

  35. 陈怀临 于 2010-12-23 6:07 下午

    这些所谓的Zero-Overhead Linux的东东，估计现在都差不多。

    我现在也不知道大弟子是如何做的了。但我认为做多核系统最后的秒杀就在与：Cache的最佳利用。

    目前我就没看见不糊涂的。。。

    我算一个比较明白的，说良心话。

    在有L3的CPU上，如果能把cache充分利用好。大事就成了。

    许多读者对我大弟子的性能，sorry，我大弟子做的系统的性能，非常跌眼镜，然后天天被自己的老板抽。或者被强迫对着任选，sorry，毛选，宣誓。其实都不好使。。。

    其实要好好想想cache的事情。。。

    当然，最好的办法是：有事找首席。。。

  36. Panabit 于 2010-12-23 6:36 下午

    诚如首席所述，一切的关键都是CACHE，TLB等等呢个，这些在实际流量中的表现更是如此。多核中要尽量避免CACHE POLLUTION、CACHE乒乓、伪共享这几个CACHE杀手。

  37. 陈怀临 于 2010-12-23 6:41 下午

    大弟子，你就点到为止了。。。希望明白的人能明白。

    我这几天写一个Page Coloring的文章吧。也算暗示和帮助我大宋一些公司吧。。。

  38. xiaosuo 于 2010-12-23 7:12 下午

    这个paper详细：http://lwn.net/Articles/259710/

  39. 打酱油的 于 2010-12-23 7:55 下午

    intel Q6600，82576，64bit，10Mpps，给力吧。
    只用了一个core

  40. Panabit 于 2010-12-23 8:32 下午

    回楼上，挺给力的！！！回38楼，那个PDF真好，拜谢了！

  41. Panabit 于 2010-12-23 8:53 下午

    39楼：加入我们的“给力，X86“系列吧，人多力量才大。

  42. 打酱油的 于 2010-12-23 9:01 下午

    一直就坚持抱粗腿的理念，紧跟x86阵营

  43. 打酱油的 于 2010-12-23 9:03 下午

    更正：64byte

  44. Panabit 于 2010-12-23 9:12 下午

    哈哈

  45. roccen 于 2010-12-23 9:33 下午

    39楼，是几个82576并行出10Mpps的？ 一个82576上用了几个队列？ 单流单队列的最大吞吐能做到多少？

  46. Panabit 于 2010-12-23 10:37 下午

    我估计他应该是4个82576 PORT，这个最主要的是芯片组，如果是一个Core的结果，多队列，，单队列关系不大。

  47. Panabit 于 2010-12-24 9:02 下午

    Sorry,应该是4个82576 CHIP。

  48. Panabit 于 2010-12-29 7:28 上午

    今天初步测试了第三代PANAOS，提升明显，第一次觉得10Mpps是如此渺小。继续努力中……

  49. 打酱油的 于 2010-12-29 4:32 下午

    10Mpps都渺小了？什么世道。x86还真是给力。期待具体结果。

  50. Panabit 于 2010-12-29 6:42 下午

    楼上的，你也加入我们吧，一块给力，呵呵。

  51. 打酱油的 于 2010-12-30 3:14 上午

    怎么加入?

  52. Panabit 于 2010-12-30 6:34 上午

    你联系我吧，我的联系方式：softmic_mao@126.com

  53. liang 于 2010-12-30 5:04 下午

    Intel的cave creek不会像IXP2400一样吧，记得当时2400在安全行业也燃烧了一下，之后不得不折腰了，搞得买了几块2611的板子搞开发。

  54. 帝释 于 2011-01-03 12:23 上午

    给力，为什么一定要用X86解决问题。NP+ASIC应该更有专用化的发展空间。

  55. 理客 于 2011-01-03 8:38 上午

    安全是个有很多软件定制化空间的市场，不是一两个C/J等大鳄能通吃很大的，所有能容下众多缝隙给很多有自己特色的安全产品小厂商，而NP+ASIC，不是中量级以上的选手，如果要强上架，是可能KO死人的。所以基于高性能的X86平台/MIPS多核+Linux定制软件平台，是有充分的市场空间的，如很多人所看到的，X86因为历史定位的原因，在IO一块借用现在流行的词，不给力，所以一个好的Linux安全平台+X86 IO优化，是很好的market，比如panaOS的产品

  56. MIPS 于 2011-01-03 11:49 下午

    多核+X86，或者多核（例如TILERA PRO64, 或者GX100）可能更容易开发，软件使用SMP Linux+ZOL的编程方式。

  57. boblee2000 于 2011-01-10 8:07 下午

    嗯，发表下个人看法，我觉得panos应该是修改了一些linux的调度机制，使得可以在用户用户态创建脱离于linux内核调度机制的线程或者进程，让cpu能够将绝大部分性能用在用户自己申请的线程或者进程上以提高用户态的处理性能（和那个rtlinux类似）；至于收包，肯定是用了类似零拷贝之类的原理，可能panos的cache做的比较好的优化。个人觉得，就目前来说多核处理的最大问题还是软件，现在已经很多公司意识到了这个问题正在解决这个问题。一旦解决了，多核还是未来网络应用的主要平台

  58. system 于 2011-01-10 10:18 下午

    TILERA的ZOL 就是实现57的想法

  59. Panabit 于 2011-01-18 8:39 下午

    57楼：Panaos不是基于Linux的，是跑在FreeBSD上的一个进程。

  60. Will Chie 于 2011-01-18 8:59 下午

    Panabit兄注意避免技术泄露。

    最近关于TILERA的鼓吹的人特别多，这些人有两个特点：
    1.不做技术的，根本讨论不了技术问题，上来就是胡吹；
    2.根本不是业内的（我所认识的业内的都BS他家处理器），可能是像Meganovo那些搞平台的被T家忽悠了，搞通信又搞不清楚，出来顺便套点技术。

  61. Will Chie 于 2011-01-18 9:10 下午

    发现所有的T家处理器的内容都有严重的5毛党行为。

    水军杀入弯曲了。

  62. Will Chie 于 2011-01-18 9:19 下午

    通过boblee2000评论可知，根本不知道现在国内的通信厂商的多核架构是怎么做的（懂得的人都懂得，我就不说太多了），怎么就能挺T家处理器能在通信行业成功呢？

  63. Panabit 于 2011-01-18 9:47 下午

    Will，慎言，慎言，大家都不容易，呵呵。无论是哪家，我们都应该祝贺他们，希望他们成功。:)

  64. peter liang 于 2011-01-18 9:57 下午

    谢谢Panabit兄, 非常期望和你合作呀，昨天在你楼下给你电话，可没人接呀。

  65. Panabit 于 2011-01-18 9:59 下午

    Peter，我接了，不知道什么缘故断了，因为当时在开会，开完会很晚了，就没打回去。

  66. MacOS 于 2011-01-23 7:38 上午

    82574跑不到线速么？那还叫什么GE controller啊！他和82572/82571在内部有什么区别呢？

  67. 大黄蜂 于 2011-01-23 6:37 下午

    做作网卡的应该会比较清楚的。cpu转发时，大部分时间是网卡都在等待cpu分配主存的指针链表。无论上行下行都有这种情况。中断处理应该是个瓶颈，采用轮询也没多大改善。

  68. george 于 2011-03-07 11:50 下午

    10Mpps 1个核应该不渺小，相当好了。
    看了WR的产品，最高性能才21Mpps,这个指标应该是用极限硬件做出来的。

  69. 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也统一评估。

  70. kernelchina 于 2011-03-08 2:47 上午

    不明白这种评估有何意义？给OEM厂商一个参考？

  71. Will Chie 于 2011-03-08 3:06 上午

    评估硬件性能，对硬件进行选型。
    通过多组不同的测试找出硬件性能瓶颈点。
    以此为基准，评测上层软件性能，并进行优化。

  72. Panabit 于 2011-03-08 4:15 上午

    回70楼：目前没有想过太多的什么意义的事情，只是觉得目前这个事情没有人做，就想做做而已，呵呵。不管怎么样，先做再说，至于到底是否对他人有意义，有帮助，那是老天决定的。只要没有副作用就行 :)

  73. 打酱油的 于 2011-03-08 5:34 上午

    当然有意义，坚决支持Panabit。

    有一点小疑惑，为什么总线会影响结果？理论上这里应该是足够的。是不是软件写的还有点问题？

  74. Panabit 于 2011-03-08 5:46 上午

    回楼上，总线只是我的一个猜测，不过的确和transaction速率有很大关系，这个我已经验证过了。当然，软件也会有一些关系的，不过到这个层次，基本上软件能做的不会太大。软件能做的可能就是尽量减少代码对CACHE的POLUTION和消费，因而避免和总线抢CACHE的（总线会SNOOPING）。我还在优化，也在等待新的平台验证我的一些猜测。

  75. 打酱油的 于 2011-03-08 6:04 上午

    现有的安全网关产品没一个能和你的结果接近的，把精力放在功能上吧，更能体现价值。

  76. Panabit 于 2011-03-08 6:33 上午

    谢谢楼上，你说的没错。这些优化以前也是抽空进行的，主要还是要功能做上去。这段时间因为要弄Panaos3，所以专门花了一些时间优化，俗话说，磨刀不误砍柴工，我们希望将这个平台做得扎实一些，特别是首席经常教导我，要实现考虑周全调试手段和方法，并且每个步骤是可量化的。

  77. 阿土仔 于 2011-03-08 7:52 上午

    大家说的小包这么高的性能，是指都被cache住的情况，比如很少的流，还是随机的情况？

  78. 老韩 于 2011-03-08 7:10 下午

    积极调动资源，鼎力支持Panabit做这件有意义的事情

  79. 十分八卦 于 2011-03-08 7:25 下午

    不用凡事先考虑个意义吧，不过要说意义可多了，比如：

    对辽国的意义：辽国的I公司一直在找6W和WR来调试他的转发能力，花了不少的时间和金银，这次RSA也有demo。Panabit这个性能，特别是打开业务后的性能，显然超过了那个水准，对I来说是莫大的喜讯，等于有人从侧面佐证了他的solution不错嘛！

    对大宋厂商：除了H/Z之类的大鳄，大家说到底还都是软件公司，而对软件厂商而言硬件平台的选择无疑是重中之重。君不见圈内N个先烈受了别人的忽悠，选了自己不擅长，无法handle的硬件平台，白白浪费时间和精力，换不来一个稳定的产品。从这个角度说，Panabit的工作是在为大家指出了一个可以参考的方向。

    对大宋民族的意义：俺们有了个telecom data plane可以自豪的专业os，领先辽国的哦，感谢diang，感谢银民,感谢核高基，感谢ccav………的无视

    对首席的意义：Panabit言必称在首席的哼哼教导下，大弟子光荣，这师傅也沾光不是。

  80. Jackson 于 2011-03-09 12:15 上午

    华为早就在5500+598上把转发做到10Mpps以上了

  81. 老韩 于 2011-03-09 12:17 上午

    78楼说得对啊，这事得找Intel支持，他们不给力实在说不过去了

  82. kernelchina 于 2011-03-09 2:50 上午

    非常不错，panabit做的事情对厂商有意义，不过就是自己受累的，景仰。

  83. Panabit 于 2011-03-09 4:41 上午

    回80楼：这个事情早就知道了，Intel为了推动HW，还专门弄了一个测试的PPT，应该说是Intel将其做到10Mpps以上。

  84. tawl 于 2011-03-09 6:39 上午

    这种测试明摆着是自己必须要做的，奇怪82楼的视角。。。

  85. 理客 于 2011-03-09 6:41 上午

    大公司确实非常有利的先发资源优势，不过就实际个人能力，还是Panabit比较强

  86. 打酱油的 于 2011-03-09 7:35 上午

    世界上怕就怕“认真”二字。
    大公司打工仔还真搞不好这一套

  87. 理客 于 2011-03-09 7:50 上午

    对大工程，大公司还强在只要有高人指点（CTO）和高人组织（CEO），强大的正规大兵团作战，威力撼人，所向披靡，具体可参考美帝国防部的项目

  88. xie 于 2011-03-12 4:51 上午

    TO 83楼，网上貌似找不到你说的PPT，能否给个链接。

  89. Panabit 于 2011-03-12 5:02 上午

    回楼上：这个PPT是Intel给HW提供的，不是公开的。

  90. Arthas 于 2011-03-12 5:44 上午

    优化CACHE, 一个Core应该可以做到小包8G线速? 相当的给力啊.
    Panabit 向你学习啊..
    能否交流交流?

  91. 陈怀临 于 2011-03-12 10:37 上午

    Panabit，我们要好好考虑如何把PANOS的经验总结出来，并在学术界和工业界发一篇震撼宋辽的文章。功德无量。。。

  92. ORG 于 2011-03-12 2:20 下午

    不在架构好坏，还是看水平高低

  93. kernelchina 于 2011-03-12 8:50 下午

    cache优化需要对code path和memory footprint非常了解，也就是对自己的代码要非常了解。而且在功能加到一定程度，感觉cache优化是有心无力。

  94. xie 于 2011-03-12 9:31 下午

    期待首席和首席大弟子的大作。。。啊弥陀佛。

  95. 行者千里 于 2011-04-19 1:01 上午

    说实话，我看到Panabit做的这个测试，非常感动。我们一直在做X86架构的硬件网络平台，从CPCI到普通的网络应用板卡，但是由于是做硬件的，对网络的测试没有成系统，这个测试确实帮了大忙。国内做X86硬件的，由于发生过断代的问题，或者说国内的产业就是比拼价格，真正实实在在做的，留下来的不多，做的好的就更少了。希望“弯曲”这个平台，提供更多的“给力”，让我们把产品做的更好。在X86有10几年了，希望在这个平台认识更多的朋友。

  96. tom 于 2011-05-23 7:14 下午

    据说，xx公司，已经跑出了更高的性能

  97. Panabit 于 2011-05-23 8:55 下午

    楼上：具体数字多少？这个数字还应该有40%的提升空间的。

  98. Panabit 于 2011-05-23 8:59 下午

    上面说的40%，是指小包，大包已经满了。

  99. multithreaded 于 2011-05-23 9:27 下午

    Let’s do a simple caculation here.

    Assume a 10MPPS speed (64B packet) and the CPU frequency is 2Ghz. Then each packet should be processed by 100 x 2 = 200 cycles. I.e., each packet can tolerate no more than one DRAM access.

    This also suggests that RX has little cache miss rate :-)

    If you want to improve it further like 40%, I doubt it is a sustantable speed since it means everything is in the LLC.

    By modifying Linux driver, we could have 10/11 MPPS per core on Intel NIC 82598/82599. With RRS/MSI-X we can then easily handle 15MPPS (10Gbps linerate) using 2-cores. However the question remains whether we could develope network applications to take advantage of such HW based load balance scheme.

  100. Panabit 于 2011-05-23 9:28 下午

    我们目前评估的结果是：82574小包大概能到58%左右，不知道还能否继续提高。以前小看了这个芯片，现在发现还是软件不行，呵呵。

  101. sniper 于 2011-05-23 9:31 下午

    裸奔到这么快还是很厉害的，剩下来的主要是看很多具体业务加上去以后是否会性能降的厉害，如果直线下降的话可能只能玩玩了，毕竟裸奔到这么快一个很便宜的switch芯片能轻松做到。。

  102. Panabit 于 2011-05-23 9:35 下午

    回99楼：我没说你的那种情况下提升40%，我是指N270这款硬件而言的。10/11Mpps per core，这个数字是比较不错的数字了，但是它的扩展性需要验证一下。我们发现，单核做到这个数字完全没问题，但是要扩展到3~4核以上，单核PPS立马下降。

  103. Panabit 于 2011-05-23 9:37 下午

    回101：如果做一个类似防火墙的快转，那么结果大概是裸奔的60%左右。有裸奔的基础，才有业务的基础。SWITCH是没法做业务的。现在大家说X86性能不好，普遍是因为裸奔上不去。另外一个例子是，XEON在裸奔和业务情况下，性能结果差别不大，从这里才体现出XEON和一般的非XEON的U的差别。

  104. tcpip 于 2011-05-23 9:50 下午

    @multithread, RRS/MSI-X -> RSS/MSI-X

    高性能的转发涉及到的东西不多，因为直接面对的就是硬件，想办法把硬件的能力发挥出来就能得到很高的性能。

    但是网络应用程序的性能提升感觉比较困难，系统的复杂度比提升转发性能高不少。那位大侠有经验给科普一下。

  105. multithreaded 于 2011-05-23 10:11 下午

    谢谢！ 应该是RSS （Receive-Side Scaling).

    即时是转发也需要非常大的routing表 （1M entries)，它会和RX抢LLC的。

    我们的RX能达到10MPPS+的速度，the cache miss rate << 1 per packet.

  106. multithreaded 于 2011-05-23 10:16 下午

    >但是要扩展到3~4核以上，单核PPS立马下降。

    Are the 3-4 cores in the same NUMA node?

  107. Panabit 于 2011-05-23 10:41 下午

    YES, same NUMA node.

  108. 屁股抽筋 于 2011-05-24 12:53 上午

    畅想一下：在sandybridge上，由于内置GPU，那么把路由表查找、IPSEC加密、哈希计算等耗费CPU cycle的动作扔给GPU（如果只有少量这些处理需求则可以扔给AES-NI指令和AVS指令），有没有可能实现高性能软件VPN啊？记得以前也有厂商号称基于westmere平台搞定40G bps，不过一上IPSEC立马下降几十倍，只有接近1G bps

    如果能冲击到目前企业边缘的ASR路由器市场，那可有好戏看了！我强烈看好Panabit他们的工作

  109. Panabit 于 2011-05-24 1:24 上午

    在SNB上实现高性能的VPN，一点问题没有。

  110. Jesus 于 2011-05-24 1:37 上午

    是用GPU来做加解密么？是不是不如来一块cavium卡来的简单啊？毕竟编程复杂度就不在一个级别，而且用GPU来做加解密的成本会不会比cavium卡还要高啊？

  111. liang 于 2011-05-24 2:41 上午

    to panabit：
    请教一下intel 5520 + 82599卡，标准linux(kernel 2.6.35+)路由转发能达到多少? 需要注意什么？

  112. Panabit 于 2011-05-24 3:56 上午

    回楼上：我没有测试过Linux，不过我知道有厂家用X5650可以做到小包2.8Gbps。

  113. Panabit 于 2011-05-24 3:57 上午

    上面2.8Gbps数字用的是标准的Linux，具体内核版本我不清楚。

  114. 屁股抽筋 于 2011-05-24 4:25 上午

    > 但是要扩展到3~4核以上，单核PPS立马下降。

    是因为内存时延的瓶颈吗？
    另外有个问题觉得比较费解：一般来说多核包处理应尽量让一个报文全流程都让一个核搞定，不要中途切换，避免cache污染，但哪些做NSP多核CPU的，几十个核之间玩pipeline，还不得不做cache一致性，不是费力不讨好吗？是不是根本就应该不用pipeline这种方式？

  115. WHowe 于 2011-05-24 4:44 上午

    请教 Panabit, 同样的平台，按你的经验 82574 相比 82576 性能上大概有多少差距？

  116. Panabit 于 2011-05-24 6:21 上午

    所有接口为PCIE * 4的网卡，如82571，82575,82576和82580都可以小包线速。所有PCIE * 1的网卡，如82572,82573,82574目前还做不到小包线速，82572和82573因为现在比少见，所以没有测试过，82574目前能做到58%左右的小包线速。

  117. 屁股抽筋 于 2011-05-24 6:50 上午

    看来x86用于通信大势已成，不知道那些cavium，rmi之类的多核CPU，优势还有多大。而且那几十个核居然搞pipeline方式，又费一包子劲要注意cache一致性，真是别扭

  118. fastpath 于 2011-05-24 7:07 上午

    c114上前两天闪过一篇文章但很快被斑竹删了，说Cavium多核在华为现网出现问题，搞得H很不爽。这事靠谱嘛，还是瞎放炮。

  119. 文海 于 2011-05-24 7:38 上午

    性能优化就是匠人手艺，做好了就是巨匠，可以享受现世的荣誉和繁华。

    基本原理和架构属于坐而论道，做好了就是大师，可以享受荣誉未必能够享受现世的繁华。

    匠人手艺要讲究快速回报，希望尽快赚到真金白银。

  120. tom 于 2011-05-24 8:41 下午

    回panabit，性能我听说比你们要高20%左右

  121. Panabit 于 2011-05-24 8:44 下午

    是指上面测试结果的20%？

  122. tom 于 2011-05-24 11:40 下午

    恩，我应该没记错，525的

  123. Panabit 于 2011-05-24 11:55 下午

    嗯，那还要增加20%才可以 :)

  124. wan 于 2011-06-27 7:01 下午

    @Panabit and all

    笔记本的千兆网卡，芯片有没有intel 8257x的。
    想买一笔记本，用来调驱动。

  125. Panabit 于 2011-06-27 7:06 下午

    笔记本的用8257X的很少。

  126. gaohl 于 2011-06-27 7:57 下午

    好像thinkpad T系列是intel千兆的网卡芯片，但是具体型号不记得了。

  127. Panabit 于 2011-06-27 8:43 下午

    是千M的，但大多是8256X的，8257X的我暂时还没有看到过。

  128. gaohl 于 2011-06-27 8:54 下午

    请教panabit，不知道咱们是否关注RFC 2544的back to back的指标

  129. wangee 于 2011-06-27 9:40 下午

    求Panabit优化方案。
    陈首席和kernalchina把自己的优化方案都贡献出来了，Panabit可否有点open source的精神？只看对性能的吹嘘实在没劲啊。

  130. kernelchina 于 2011-06-27 10:21 下午

    panabit人家那是核心技术，是商业机密，我讲的都是common sense，顶多就是个总结，所以不可同日而语。Driver的优化很多是硬件相关的，指导原则就是这样，具体的要自己琢磨。

  131. Panabit 于 2011-06-27 11:12 下午

    128:RFC2544 back to back指标和吞吐有多大的区别？我看了一下它的定义，也没太看懂，请赐教！

  132. gaohl 于 2011-06-27 11:36 下午

    测试这几年一直对于此back to back指标不解，哪位大牛了解，同求赐教！
    小弟之前做过linux的对比测试，修改linux的网卡rx和tx的大小从256-4096，只增加64Byte的一倍的btob的转发帧数量，不解中。。。

  133. wan 于 2011-06-28 12:18 上午

    对于开源软件，开源不是目的，通过开源得到反馈、和patch等才是目的。

    对于Panabit，开源没有意义，免费的限制版本很有意义。

  134. tom 于 2011-07-03 9:19 下午

    背靠背，好像是测试最大突发帧数吧？我一直也没理解这个到底有什么意义。。。。

  135. Natalia 于 2011-07-08 8:19 下午

    back-to-back形容的是帧，不是DUT。就是帧以最小IFG(很形象是不？) burst。可以测试DUT缓存容量。至于意义，RFC 1242说的很清楚，可以参考一下。

  136. gaohl 于 2011-07-08 8:49 下午

    了解了，感谢楼上的推荐！

  137. Panabit 于 2011-07-08 9:18 下午

    谢谢135楼的解释。

  138. SNB 于 2011-07-13 2:11 上午

    Panabit有没有考虑过基于Xeon E3-1275做个测试呢？这个东东集成GPU，用得好应该对加密解密和内容识别还有流处理有很好的加速作用，很期待测试结果呀

  139. Panabit 于 2011-07-14 12:09 上午

    回楼上：GPU我现在也只是出于摸索阶段，还没有用上。XEON E3-1275下周会有一个厂家送一台过来，我会仔细评估一下。我也很期待，呵呵。

  140. Panabit 于 2011-07-14 12:18 上午

    顺便在这里呼吁一下：如果有哪个厂家对自己的硬件有信心，也希望评估一下结果，可以来找我们。我们上次就在评估一个厂家的硬件时，发现了以前他们没有发现的现象（是否是问题还有待评估）；我们也发现了即使同样规格和配置一模一样的两个厂家的硬件在性能上的显著差异。而使用标准或者优化过的Linux是根本发现不了这些差异性的。

  141. XiaoQiang 于 2011-07-14 12:45 上午

    用GPU做加解密？是同步呢？还是异步呢？如果要支持gather scatter，会不会实现起来太复杂呢？但如果不支持异步运算和gather scatter，意义大么？

  142. XiaoQiang 于 2011-07-14 12:47 上午

    如果是PANOS用GPU，应该是用来做应用识别，这个很给力，但也面临同步异步，及是否因为免重组导致问题过复杂的问题。

  143. SNB 于 2011-07-14 2:04 上午

    按照GPU的编程模式，肯定是要批量启动代码逻辑相同的任务(好像是32个为一个单位吧，至少NV如此，AMD更高，Intel可能灵活些)才合算。但另一方面SNB的GPU和CPU共享L3 Cache和内存，应该可以加速不少，至少CPU扔给GPU后cache肯定可以命中了。

    to Panabit：你们测试1275会把它的GPU用起来吗？

  144. SNB 于 2011-07-14 2:10 上午

    to XiaoQiang

    我觉得加密解密是最给力的，因为这里面完全没有代码分支，运算步骤固定，而且好像GPU在网络方面的通用计算这方面的论文也是最多的。当CPU解决了基本IO转发问题后，剩下的加解密和模式匹配等密集计算问题就轮到GPU发力。严重期待高性能x86 VPN，估计这是RMI/Cavium等最后一块阵地：）

  145. XiaoQiang 于 2011-07-14 4:02 上午

    我不怀疑GPU能做加解密的性能，我只是觉得它做加解密的软件复杂度比专业加密芯片复杂度高太多，因为对于异步加解密，还有gather scatter，专业加密芯片已经有很好的支持，但如果用GPU，都需要自己来搞队列、加密状态等东东，复杂度高出很多啊。

    当然，如果做成同步，并且不支持gather scatter，另当别论。

  146. 行者千里 于 2011-07-18 8:01 下午

    to Panabit
    我们是硬件厂家，如何联系你们?我可以提供样品,包括后续的硬件产品，我们都可以提供。甚至我们也可以优化自己的BIOS。我的QQ是332445776.谢谢

  147. Panabit 于 2011-07-18 8:22 下午

    My QQ: 896416263

  148. zhoujin 于 2011-07-19 12:41 上午

    要是还是想用intel的X86，对cvm和rmi的货期等等不满的话，建议了解一下DPDK，一个intel全新的开发套件。intel宣称一个1.2G的一个core，就可以达到100%的效能。10G进10G出。但是开发程序和之前我们所理解的X86应该不是一个概念。有兴趣可以进一步讨论。但是个人觉得网络流量不断的增长，要是不想掉队，就不能回避多核或者MIPS.抛开程序开发难度，intel传统的X86在网络应用上有很多瓶颈是过不去的，市场的下降，intel也在做深刻的反思，1，效能上不去。2，价格下不来。正是这些，才有了DPDK的诞生。目前我所知道的**公司实际应用，已经达到70%的效能，10G进去7G出来。 qq：237993928

  149. 贝壳 于 2011-07-20 6:06 上午

    楼上说的确定没问题，同时性能可以随核数倍增，希望弯曲出一篇文章专门讨论DPDK，这是INTEL版的PANOS思想，同时开源

  150. 根本不相干 于 2011-07-20 7:41 下午

    http://download.intel.com/embedded/applications/networksecurity/323814.pdf

    好像的确如此，似乎是把目前已经广泛使用的一些手段(如以poll方式接管linux kernel driver)，用SDK的方式把它标准化提供出来，降低新进入者开发高性能x86网络设备的门槛。

  151. QV 于 2011-07-27 3:10 下午

    Using the fast path of the 6WINDGate from 6WIND on Intel processors, you can sustain up to 100% of 4 x 10Gbps PCI NIC per Intel processor (64 bytes packet). It worths trying ;)

  152. multithreaded 于 2011-07-27 7:57 下午

    Assume using 8 links like Intel NIC 82599, the peak performance for PCI-e 2.0 is

    5Gb * 8 = 40Gbps.

    It is very hard to reach the theoretic speed in practice. Therefore, I doubt it can handle 100% of 40Gbps. Even if it does, it is unsustanable speed in practice.

    Therefore, the bttleneck is NOT CPU but the PCI-e 2.0

  153. 阿土仔 于 2011-07-28 2:49 上午

    to multithreaded:严谨一点，PCIe至少有8b/10b的开销，理论上峰值在32Gbps

  154. multithreaded 于 2011-07-28 7:45 上午

    Thanks. It further proves that any claims on 100% of 40Gbps processing is incorrect.

  155. 飞舟 于 2011-07-28 8:37 下午

    很高兴看到这样的测试. 对于俺是一个不错的参考.

  156. QV 于 2011-08-01 5:22 上午

    To: multithreaded

    53Mpps using 4 ports of the IXIA for a bench that has just been run.

    The board is made of 5 PCIe slots, 4 of the 5 slots are used (PCIe Gen3 x8, 16GB/s each).

  157. Multithreaded 于 2011-08-01 3:41 下午

    Which Intel processors are used? None of Intel multic-ores on the market supports PCIe 3.0 yet.

  158. txwwy 于 2011-08-01 9:07 下午

    maybe Ivy Bridge ?

  159. QV 于 2011-08-02 3:09 下午

    http://www.6wind.com/6windgate-faq#id113

  160. ask 于 2013-02-26 7:53 下午

    问Panabit一个问题，

    82574L网卡加上类似酷睿i5这种高性能CPU，能达到转发线速么。

  161. Panabit 于 2013-02-27 5:38 上午

    目前为止，我还没发现用82574可以做到64bytes线速的平台，最高的做到了70%左右。

  162. void 于 2013-02-28 12:58 上午

    真千兆和准千兆的区别

  163. isofish 于 2013-02-28 1:16 上午

    我们公司也一个和Wind River Network Acceleration Platform类似的基于Linux用户态的IP数据包处理产品，不过公司重点不在这个领域，投入资源不足。下面是在Freescale P3041上的单核测试性能。
    Frame Size Intended Throughput Theoretical Throughput Theoretical
    (bytes) Load (%) (fps) (fps) (Mbps) (Mbps)
    64 86,078 2,561,849 2,976,190,476 1,721,562 2,000
    128 100 1,689,189,2 1,689,189,189 2,000 2,000
    256 100 905,797 2,905,797,101 2,000 2,000
    1 024 100 239,463 7,239,463,602 2,000 2,000

  164. isofish 于 2013-02-28 1:20 上午

    数据好乱，不知道怎么粘图片？

  165. Jamie 于 2013-02-28 6:23 下午

    当年（08年前后）就Intel的PCIE网卡（型号忘了，有好几款，应该都是825XX的）做了零拷贝驱动，在应用层打印一下IP头部，就转发出去，两块网卡，能做到64byte双向都是1G线速收发。服务器是8核的Intel CPU（忘记型号了），用了2个核。

  166. multithread 于 2013-02-28 10:32 下午

    Intel的82575/82576应该能做到的.

  167. Panabit 于 2013-03-01 1:58 上午

    只要是PCIE*4接口的，都很轻松的做到线速，包括比较老的82571。

  168. multithread 于 2013-03-01 8:24 上午

    有没有见过1G的光口NIC？ Intel的NIC都是铜口， 要把铜口转成光口。

  169. Panabit 于 2013-03-01 5:46 下午

    楼上的，？

  170. aaaa 于 2013-03-02 6:58 上午

    INTEL的光口NIC 满大街都是啊！！

  171. multithread 于 2013-03-02 7:40 上午

    我想按一个转换器之类的东东把现有的铜口转换成光口。

    如果不行， 就只好直接换光口的NIC。

  172. kevint 于 2013-03-02 9:28 下午

    82576是1G的吧
    i82599 base的nic是1G/10G自适应的吧
    你插1G的sfp就跑1G了。。。

  173. multithread 于 2013-03-03 12:19 下午

    Yes it works. However, it is too expensive to be used in practice.

  174. ask 于 2013-03-03 6:07 下午

    感谢Panabit回复。82574接口是x1的PCIE，很难到线速。82571/6等都是x4或更高端的控制器，跑到线速很容易，不能说明什么问题。

    还有一个问题，我现在用的PC机是PCH2_LV_LM + 82578DM的PHY core i5 CPU，系统也一下子也是线速。82578DM的手册上写的是
    The 82578 can be connected to any x1 PCIe port in Intel® 5 Series Express Chipset.
    The PCIe port that connects to the 82578 is selected by PCHSTRP9

    这种情况是因为集成南桥PCH的性能比82574 controller好的原因么？

  175. Panabit 于 2013-03-04 12:13 上午

    从理论上说，X1是可以做到线速的。我前面说的82574不能做到线速，只是从实际现象出发的。82578没有评估测试过，所以不好评价。你确定82578连的是X1？我映像中有寄存器可以读取这个信息。

  176. ask 于 2013-03-04 12:54 上午

    不敢确定，还不知道读。根据手册，82578/7/9都是一种PHY，可以通过PCIE和MAC连接。按照手册描述，可以通过x1 PCIE连接，手册没有确定必须用x1。按照PCIE规范，单lane峰值带宽2.5GT/s，这里能说有2.5G，单向1.25G网络带宽的潜力么。