“盛科CTC6048参数和MPLS-TP解密”有43个回复

1. 核撼叁 于 2010-12-29 8:46 下午

   老大，这两天我大宋的丝带鸡出来了，您给评论一下
   http://www.youtube.com/watch?v=R4UQ9PFE1uY

2. 陈怀临 于 2010-12-29 8:54 下午

   你得了吧。我可不想被人请去喝茶。。。另外，阿啦也不懂呀：-）。。。我倒是关心这里面的OS和CPU是不是：龙芯+麒麟；或者汉芯+红旗？：-）

3. 关注过盛科的人 于 2010-12-29 10:10 下午

   我觉得盛科发展这么几年了，关键是管理问题 – 现在海归，回来做公司的几个通病。譬如：对员工的诚信问题，

   首席，你跟盛科的founder是校友还是同学吧？支持也是应该的。呵呵！

   另外，L2 100G能比L3 router省多少Power？接入汇聚层总是要电层处理的，ME多用光处理，光纤和端口都能收敛，不是更好？首席，您认为呢？

4. Sam 于 2010-12-30 5:15 上午

   PCI而不是PCIe接口，现在的M,B的Switch都是PCIe的了

5. 盛科 于 2010-12-30 7:24 上午

   Sam，确实CTC6048用了PCI而不是PCIe接口。和B/M不同的是我们的PCI只用于控制配置，芯片和CPU的协议报文交换有专门的CPU GE口（可升频工作）。当时考虑主要包括：
   1. GE口的效率要比用DMA over PCIe传报文效率高；
   2. 支持PCI和GE口的CPU成本低
   3. CPU GE扩展性好。如我们可以在CPU 和CTC6048的GE联接之间加上FPGA，用作MPLS-TP OAM 的offload 扩展。如用PCIe和DMA传CPU报文则会相对困难。
   如果我们也用PCIe，您会建议我们保留CPU专用GE口吗，还是建议我们直接用PCIe的DMA？谢谢。

6. guigui 于 2010-12-30 5:02 下午

   赫赫，写这个白皮书的人貌似对OAM和APS还很熟啊

7. Jerry 于 2010-12-30 5:33 下午

   to 5楼，
   你的回答１有偷换概念之嫌。。要跟dma over pcie比效率的话，那你不能用ge口的效率比，而应该用ge的pkt over pci来比。
   用专门一个ge的问题是在ge包很快，甚至wire　speed的时候挂在pci的cpu是否能接的住，处理的过来。bottleneck应该focus在这里。

8. Jerry 于 2010-12-30 6:04 下午

   刚看了一下你的回答３，应该说是用pkt over fpga来比，以及挂在fpga上的cpu,不过问题都是一样的，仍然需要在fpga上做dma，fpga的速度与chip上的pcie的速度不是一个档次

9. 我是我 于 2010-12-30 7:06 下午

   用PCI，而不用PCIE，成本低是关键，另外，技术复杂和功耗是否也低？

   但是，PCI最大的一个问题是，PCI接口的CPU/MCPU越来越少，这是个潜在问题。

10. 我是我 于 2010-12-30 7:24 下午

    一个问题关于：2K queue, flexible queue mapping, configurable WRED profiles

    What’s size of each queue? are shared by 48*1GE+4*10GE, right? this is cared.

11. ABC 于 2010-12-30 7:36 下午

    To1楼的，丝带出来是说明我能造就能拆，大辽丝带也一样。

12. 盛科 于 2010-12-30 9:41 下午

    Jerry:
    我的意思是我们用PCI做芯片数据结构和寄存器的控制，用专门GE口（第49个GE口， 49er：：）做CPU报文传送，DMA在CPU内部网口和内存之间，效率一般很高。
    B/M是用PCIe，控制和CPU数据报文都是PCIe传送，DMA在交换芯片和CPU之间通过PCIe实现。
    当时的一个设计选择吧。随着主流CPU想PCIe转换，我们也会支持PCIe，很想听听是否有必要保留第49个GE口做专门的报文传送。

13. Jerry 于 2010-12-30 11:38 下午

    to 楼上，个人感觉如果打算支持pcie的话，专门to cpu的ge port完全可以拿掉，pcie的bandwidth远高于1G,并且用ge port的话由于ethernet接口的来回转换反而会增加delay，当然如果你们认为cpu与chip之间的traffic不多的话可以保留现在的做法。
    个人猜测B/M在pcie接口后有可能直接将pkt内容存于dram,然后可以依靠firmware来做改变header等动作，减少cpu loading并增加处理速度，没查过B/M的资料，仅供参考

14. 盛科 于 2010-12-31 12:20 上午

    Jerry, 谢谢您

15. 我是我 于 2010-12-31 1:43 上午

    现在用多核CPU来做分布式管理的越来越多，控制面上移后，跨背板的管理，可能P2P的为多，建议GE保留。

    另外，我关心的是你们的2K queue? queue size多大？100G标准的简单化，终将淘汰40G（个人观点），下挂GE/10GE线卡/端口，如果要做到业务感知，这里的挑战很大。网络SR/BRAS并合处理，高清点播的流一上来，很担心QoS？

16. 我是我 于 2010-12-31 1:45 上午

    补充下，

    要做到用户和业务感知。

17. 盛科 于 2010-12-31 2:57 上午

    To:我是我
    非常佩服您能看到这样的点。当时设计GE口确实也考虑您说的情况。我们的CPU GE口还有一个小功能，CPU报文可以封装到不同的MAC DA,原则上报文从CPU GE口可以去不同的CPU作处理。我们尽量从系统应用的角度去设计芯片。
    QoS很不容易。100Gbps的芯片，又有保证成本。我们的2K Queue的限制实际上是片内包缓存（6MB）。至于Queue的大小，我们用LinkList实现，大小分配很灵活。原则上所有内存可以去同一个queue。
    您能否告知联系方式。非常想请教一下关于QoS的合理实现。

18. Sam 于 2010-12-31 5:09 上午

    很多GE的Switch都是100Gbps带宽的啊。10G switch上，M,B先后出了480Gbps,640Gbps带宽的Switch,很快应该有1Tbps的啦.
    请不要混淆100G端口和100G芯片带宽的概念

19. 理客 于 2010-12-31 1:43 下午

    to 盛科：
    请教一下：
    QoS在MPLS PE节点上做MPLS VPN下的复杂流分类（基于5元组以上的classification）的HQOS下是否可以达到100G线速？或者能到达什么样的性能？

20. CTC6048 于 2011-01-01 4:53 上午

    To 理客：
    我来代”盛科”回答一下这个问题。
    根据您说的基于5元组，我猜测您想问的场景应该是在ingress PE上吧。在L3VPN的时候，芯片需要做的查找包括route lookup, macSa lookup,如果再加上一次flow classification lookup，CTC6048也仍然可以做到线速。在L2VPN的时候，芯片需要做的lookup包括macDa, macSa, port+vlan->VSI mapping的lookup，如果再加上一次flow classification lookup,也恰好可以达到线速。
    我们的flow classifcation lookup，不仅可以做5元组，也可以做L2/L3/L4的绝大多数字段的任意组合。
    不过说到H-QoS，各个厂家对H-QoS这个概念的理解也不尽相同，比如有些厂家认为Hierarchy scheduling才算H-QoS，有些厂家认为Hierarchy shaping也可以算，最近MEF还定义了Hierarchy policing, 您说的应该算MEF这种吧？我们CTC6048的H-QoS应该说还是有不少特色的，比如专门有一个serviceId的概念,policing, shaping都可以基于serviceId来做，若想进一步了解细节，您可以向盛科留得email来信索取资料。
    另外，也请不吝赐教一下，你觉得目前运营商对H-QoS的要求是怎么样的？上行和下行都要求吗？

21. 理客 于 2011-01-01 3:08 下午

    to CTC6048：
    多谢回复。多级的HQOS，个人浅见，商用不多。
    您答复里的flow classifcation lookup是指基于通用的5元组ACL（SIP/DIP/PROTOCOL/SPORT/DPORT）吗？
    这里想确认的一下是基于上面的ACL分类后，对每个被分类的流分配一个队列，在多个流间作PQ/WFQ调度，这种情况下的性能是线速吗？

22. 盛科 于 2011-01-01 5:56 下午

    理客，原则上基于Flow Classification后产生ServiceID，map到不同的queue。2K queue可以顺意map到512个group，在map到不同的port和priority。多级的调度和shapping情况下可以保证端口线速。
    我们对QoS相关市场的困惑点：我们的客户设计系统，领导给他们的要求是“功能要更强，价格要更低”。QoS不如BW，features容易卖钱。如果片内buffer有限，那么多queue和QoS有用吗？如果外挂buffer,那么系统成本有竞争力吗？
    希望能听听您的意见。

23. 盛科 于 2011-01-01 6:04 下午

    To:我是我：
    另外Sam说得对，CTC6048芯片总交换和处理能力是100Gbps， 但不支持100GE端口。
    个人认为大容量下流分类，QoS处理的难点是需要多少流，多少Buffer，多少队列的定义。什么是合适的性价比。

24. 理客 于 2011-01-03 9:02 上午

    to 盛科：
    根据之前的信息，是否可以理解：
    1、支持基于5元组ACL（SIP/DIP/PROTOCOL/SPORT/DPORT）的流分类方法，并可以给这种分类的刘分配队列
    2、对于1，最大支持2K队列
    3、对于1+2的情况，可以达到100G 64字节单向线速
    我上面的理解是否完全被CTC6048的规格支持？
    一般来讲，个人认为2K队列可以了

25. 盛科 于 2011-01-03 6:03 下午

    To 理客： 您的理解正确。补充几点：
    Item 1的流分类的理论上可以支持64K个流，但map到2K个队列。
    Item 3的100G指100Gbps总带宽，不是100GE端口。

26. guanghui 于 2011-01-04 12:12 上午

    哇，盛科的Humber出来了，不错，恭喜一下！

    这个ID为盛科的是谁啊？weifeng？

27. 理客 于 2011-01-04 12:51 上午

    to 盛科：
    多谢答复。
    我理解的在1+2条件下的100G 64字节线速转化成PPS是60MPPS（package per second），是否是这个性能？

28. 理客 于 2011-01-04 1:45 上午

    to 盛科：（刚才写错了，应该是150Mpps）我理解的在1+2条件下的100G 64字节线速转化成PPS是150MPPS（package per second），是否是这个性能？

29. 盛科 于 2011-01-04 6:35 上午

    To 理客：是的， 可以做到150Mpps的调度。在保证多级调度和shapping的情况下，当时的实现还是挺不容易的。

30. 理客 于 2011-01-04 6:44 上午

    1、支持基于5元组ACL（SIP/DIP/PROTOCOL/SPORT/DPORT）的流分类方法，并可以给这种分类的流分配队列
    2、对于1，最大支持2K队列
    3、对于1+2的情况，可以达到100G 64字节单向线速
    能在一片CTC6048芯片里同时做到转发、TM、ACL叠加150MPPS，赞，太牛了！目前能够商用的芯片里，包括ALU/C/J/BRCM/marvel/NP4/X11等，没有一个能做到的！希望在市场上看到你们的商用价值证明

31. 盛科 于 2011-01-04 7:58 上午

    理客，谢谢您的鼓励。
    和B/M比，CTC6048的QoS还是有特色的，B/M习惯一个端口8个Queue。
    A/C/J更多的是产品定位和考虑到以前产品的延续发展。
    我们的资源没法和以上的任何一家比。所以谈不上牛，但确实做得很努力，从产品，到客户的支持。

32. southbayer 于 2011-02-05 11:56 下午

    150Mpps对ASIC来说不难实现吧, B/M几年前就到这个级别了. B/M最新的480Gbps和640Gbps的片子支持的包转发率应该超过150Mpps. 在高包率的前提下如果同时要求支持海量的路由查找, 或者说要求做DPI, 那就难了.

33. southbayer 于 2011-02-06 12:00 上午

    B/M已经不再是一个端口8个个queue了, 不信去查查480Gbps和640Gbps的片子的资料

34. 盛科 于 2011-02-06 2:03 上午

    To: southbayer
    您说的很对，PPS，queue实现上是工程问题（时间和成本）。关键是相应的市场是否有相应的需求。我们肯定没法和BRCM相比。只是在细分市场上提供另一个差异化选择而已。
    方便的话分享一下BRCM480G/640G芯片的队列情况。以上芯片看来主要面向数据中心，不知有否必要做每端口8个以上队列。请指点。

35. southbayer 于 2011-02-06 9:57 上午

    B和M两家的新片子出来有大半年了吧, 资料应该可以打听到……

36. viaduct 于 2011-02-26 6:39 下午

    讨论得很火热。有几点看法供参考：
    1.专用CPU GE port不一定是最好的选择。如果任意端口都可以配置成CPU port，可能灵活性更强。这个实现起来应该也不难，主要是构造一些特殊类型的包就可以了（当然还是使用正常的L2 header）。实际上PCI也好，PCIe也好，CPU GE port也好，都只是物理/链路层接口而已，可以复用同一个芯片管理模块。
    2.Hierarchical scheduling & Hierarchical shaping一般都是在一起实现的，都是由traffic manager芯片而不是packet processor芯片实现。每个sheduler都对应一个lucky bucket,可以设置shaping rate的。
    MEF定义的per-EVC/per EVC+CoS的policing还是有些简单。Hierarchical policing有一个重要作用是用来减轻TM的压力，毕竟shaping是要花钱的。
    Hierarchical policing, scheduling & Hierarchical shaping需要配合使用。
    站在更上面来考虑就是如何实现end-to-end per-flow的QoS。
    还有一个更重要的考虑点是end-to-end per-flow admission control 或者end-to-end per-flow congestion management如何实现。这个里面牵涉到packet processor,traffic manager, fabric之间需要特有机制进行配合
    3. chassis系统，通常fabric是基于cross-bar的。如果你们力推用Eth switch芯片做为fabric,可能有些方便还需要考虑的
    4. Queue的数量方面，即使在IDC的应用中，可能每端口8个queue还是必须的，另外新的做法都是把unicast, multicast分开的。
    由于ASIC中的packet buffer太小（整个行业都是这样），queue的各种参数如何tune, 以达到在各种场景下性能的平衡(throughput,packet loss, latency)可能还是要考虑的

37. viaduct 于 2011-02-26 6:52 下午

    纠正一下，从概念上讲，交换芯片本身也可以实现Hierarchical scheduling & Hierarchical shaping的，现在确实有些芯片就是这样干的。但是如果交换芯片不能外挂大量DDR3 作为packet buffer，仅靠片内RAM，即使queue的数量很多，对于某些应用还言，还是要使用单独TM芯片的，这样意义就不大。
    当然，对于使用单片方案的设计，或许还是有意义的。
    类似于MEF的Hierarchical policing应该不难实现，主要是token bucket算法上改进，以及并行流分类及增强上

38. viaduct 于 2011-02-26 7:05 下午

    刚才，没有仔细看。在640G系统上实现2K queue，6MB 片内RAM，hierarchical scheduling/shaping 确实在整个行业内还是比较厉害的。不知道支持几个级别。buffer分配不知道如何考虑的，感觉tune时需要花一些时间的

39. 盛科 于 2011-02-26 9:53 下午

    To viaduct:
    谢谢指导。 我们的理念不赞同用以太网芯片作Chassis的fabric。在fabric侧，loss-less，traffic distribution，hw based protection等都是关键问题。而且基于cell的结构才能很好的做得ingress processing 和 egress processing 的分布式处理。我们的fabric是cell based。可以到2.56Tbps的能力。
    ASIC中的packet buffer太小确实是成本/性能的一个平衡。我们的queue是用Link-list做的。分配的灵活性很强。如何tune则要看系统的应用场景。

40. Tom 于 2011-02-26 11:53 下午

    CTC6048的Functional Block Diagram和Vitesse的VSC7480框图基本一样？……

41. To Tom 于 2011-02-27 6:26 上午

    盛科的“ASIC Customized Service”，他们给Atheros也做过。

42. viaduct 于 2011-03-02 4:28 上午

    对于MPLS-TP OAM的支持泼点冷水。这个东西确实要得急，但是标准还远未成熟，甚至走那个方向都没有定下来（ 2大阵营目前正在斗得你死我活）。对ASIC开发来说，确实是非常苦恼的事情。一个方式是2边压宝，另外在架构设计时可能采用固化的硬件加速模块 + CPU core可能跟更适应变化

    虽然提了很多意见，但和首席一样，希望盛科以及国内的芯片公司能走得更好，取得这样的成绩是不容易的。

43. rudy 于 2011-06-09 1:20 上午

    请问下你们家的CT6048多少价格？有跟NL566XX做兼容性能测试吗？最大能支持到多大频率？等等