“《给力吧，x86》专题连载五：网络通信硬件平台巡览•G41篇”有21个回复

1. Panabit 于 2011-12-11 5:59 上午

   双向5G以内，G41是一个不错的性价比比较好的平台。

2. 理客 于 2011-12-11 11:29 上午

   10年前路由器的三板斧就是过ACL，查路由，做QOS，目前的X86平台在三斧齐下的情况下，performance如何？

3. Panabit 于 2011-12-11 5:52 下午

   这方面没有评估过，不好做结论，另外一方面，这些都和算法关系比较大，还有数据规模，都存在变数。

4. 新手 于 2011-12-11 7:18 下午

   文中的“业务”指的啥？是指2楼说“三板斧”吗？

5. 新手 于 2011-12-11 7:26 下午

   哪位大侠扫扫盲，LTR和TPH主要解决什么问题？

6. znzemt 于 2011-12-11 10:17 下午

   “BEM-580-F4扩展模块上的4个接口转发64Byte帧的速率超过4Mpps……而对NSP-1096全部10个千兆接口的测试结果表明，该产品对64Byte帧的整机转发能力接近9Mpps，这又意味着，之前测试中的性能瓶颈也不应该在处理器”
   — 这个有点奇怪。4个接口4Mpps，大概有67%的能力；整机10个千兆为9Mpps，只有60%的能力。使用扩展槽位的性能反而更高？是笔误呢，还是我的理解错误。。。还请解一下惑

7. 理客 于 2011-12-12 4:29 上午

   to Panabit and 老韩：
   如果X86要做路由器，就必须要做这个评估，客户并不十分关系内部算法，主要看结果：比如100个五元组ACL带端口范围+10K路由+每端口CBWFQ(PQ+WFQ)8个下的转发性能，因为这是做路由器最基本的要求，不能做这个组合，就不能做路由器

8. 老韩 于 2011-12-13 5:41 上午

   我真不太懂啊，就是随便问问，10K路由国内现在哪些环境下会用到？谢谢

9. 理客 于 2011-12-13 7:52 上午

   一般的路由器支持一万条路由不是太大，在运营商是很基本的，当然， 在企业网，可能要大中型的企业。
   对于测试，测1K也可以。

10. multithreaded 于 2011-12-20 11:50 下午

    to理客: 你说的三板斧：ACL，查路由，做QOS估计指做了一项： Lookup。

    还没有见到X86能做到10Gbps的TM。

11. multithreaded 于 2011-12-21 12:02 上午

    个人觉得路由器表应大于64K； 否则的话LOOKUP大都是一次HASH的动作。

    考虑到LLC一般是4-6MB，假定每一项用4Byte，路由器表可以做大到256K， 以考察CCache的影响。

12. 根本不相干 于 2011-12-21 12:26 上午

    考虑到LLC一般是4-6MB，假定每一项用4Byte，路由器表可以做大到256K， 以考察CCache的影响。
    ———————-

    有点没看明白，这是在测x86的路由极限，看大到什么程度能把它测瘫，还是在根据用户需求条数测它的满足度？

13. 理客 于 2011-12-21 12:43 上午

    不知道安全为什么不需要QOS？可能是安全类设备本身就不允许congestion发生，所以基本不需要OS。
    但对路由器，基本的每端口4-8个PQ/WFQ队列，是必须的，不知道X86在叠加这个路由器基本特性后有何表现？panabit有没有过评估？

14. Panabit 于 2011-12-21 10:51 上午

    没有评估过。WFQ一般是是LogN复杂度，但是中间会涉及到排序（比如堆排序），这个会导致不少数据移动，会导致CACHE POLLUTION情况频繁发生，所以要评估的话，不能泛泛评估，和具体实现是密切相关的。我们的本意是评估X86的IO能力的（因为以前大家一直对此诟病），业务相关能力和算法以及数据结构关系太密切，且缺乏标准，不好评估。

15. Panabit 于 2011-12-21 10:57 上午

    回6楼：扩展槽使用的是82580EB * 2，82580用的是PCIE * 4，所以带宽要高一些。板载的是6 * 82574,82574是PCIE * 1的，相对来说要低一些。82580本身是可以线速的，所以理论上应该是可以做到6Mpps的，现在只有4M，主要还是受总线限制。

16. 陈怀临 于 2011-12-21 11:31 上午

    单纯的Firewall不会有复杂的TM。会有一些基本的shapping，policying。软件做负责的Queue Scheduling，例如edge之上的router，还是不太现实。。。

17. 理客 于 2011-12-21 12:36 下午

    实际应用也不会用复杂的什么HQOS,N多队列，也就CAR以及每端口4-8个PQ/WFQ队列，最多是支持一下逻辑接口如VLAN interface/subinterface

18. kernelchina 于 2011-12-21 4:57 下午

    在队列多的情况下，调度就会成问题，思路就是分而治之，分布式，每个cpu负责的队列少一点。所以讲QoS还是需要了解一下有几个端口。以最简单的情况，两个端口，不支持vlan，我想x86还是能够胜任的，猜的，没实际用过。

19. 根本不相干 于 2011-12-21 5:07 下午

    软件做负责的Queue Scheduling，例如edge之上的router，还是不太现实。。。

    ———————–

    不知道软件做BRAS会怎样？

20. Panabit 于 2011-12-21 6:22 下午

    这个问题可以这样看，如果所操作的数据集基本上都在二级CACHE里可以命中，那么一个X86 CORE基本上就相当于一个ASIC CORE，X86的主频计算能力大家是清楚的。可以测试一下token bucket方式下的吞吐能力，比如定制一个永远不会抛弃packet的大的token bucket，看看一个Core能处理多少pps。

21. Taylor 于 2012-04-07 1:11 上午

    有说到散热部份,有需求可发信至
    lfli@paramountech.com.cn;