EZChip . NP4 . 100G Ethernet

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




1月19日,EZChip宣布了其100G的NP4芯片。NP4芯片的定位是在城域网(MAN)为主要市场,具体产品方向为Carrier Ethernet Switch和Router等。NP4有两款,一款是100G的NP-4;另一款是50G的NP4L。这个两款NP4在pin,package和软硬件方面都是兼容的。

读者要注意的是,NP4的100G是指单工。双工是50G。换言之,如果需要100G的进出双工,要2颗NP4。

下图所示为NP4的体系结构图。特别要注意观察的是左边的Interface图。例如10个10G Mac(这是给10G Interface的);3个支持OC-768(40G)的Interlaken接口。这3个Interlaken可以合起来形成支持100G(通过芯片外面的100G的Mac)。

下面是其100G和50GXAUI解决方案的两张线卡图:

(3个打分, 平均:4.67 / 5)

雁过留声

“EZChip . NP4 . 100G Ethernet”有181个回复

  1. 小小牛皮U 于 2010-02-01 6:23 下午

    陈首席,接口图看不到,素质,素质!

    1月28日San Jose的seminar上,有一个问题是EZChip的speaker拒绝谈论的,那就是NP4在100G线速情况下的operations per packet. 这个很关键,决定了NP4是不是credible的100G NPU。啥业务都不能实现的NPU还不如选择博通的交换芯片。

    另一个问题是RLDRAM。NP4不支持SRAM,据说是为了降低proposal的BOM cost。但是我实在是搞不明白怎么用RLDRAM去实现Statistics(包括meter)的功能。就算像其宣称的使用了什么cache技术,性能上也让我不能相信可以达到150Mpps。

    还有一个疑问点是interlaken LA。这是未来高速查找接口的方向没错,但是目前没有量产的TCAM芯片啊。起码留个标准的NSE做备选吧?等个Interlaken LA的TCAM起码要到6月份吧,还仅NL一家,对大厂来说成本风险都太高了。

    对于NP4的TM,也有一个问题。包指针不知道是存在哪里的?RLDRAM还是内部SRAM。如果是片内的话成本太高了,RLDRAM的话效率太低了。

  2. 陈怀临 于 2010-02-01 7:07 下午

    什么图看不见??我这都能看呀。。。

  3. 小小牛皮U 于 2010-02-01 7:17 下午

    现在看见了:)
    刚才NP4的Logo还有那个接口的description下了半天看不到,我的FF最近老出状况。

  4. 大荣 于 2010-02-01 7:26 下午

    谢谢首席,不知道这个是不是业界第一款。

  5. 西门青云 于 2010-02-01 7:53 下午

    关于SRAM和RLDRAM的比较

    http://www.esmchina.com/ART_8800069495_1400_0_3305_0_f48d9e43.HTM

    貌似processor中NP4是第一个采用RLDRAM的。

  6. 小小牛皮U 于 2010-02-01 7:59 下午

    不是第一个,n年前X公司的40G NPU X11就采用了。但是貌似他们下一代的100G processor已经转到DDR阵营了

  7. 陈怀临 于 2010-02-01 8:31 下午

    华为的Solar 2.0的100G也是指100单工。

  8. atst 于 2010-02-01 9:14 下午

    看了sram和rldram的比较,结论是rldram很适合高密度的包处理和大容量的表查找啊,对于统计数据来说,它的数据量不会太大,用rldram也没有问题。只是对于TM这种需要延迟的场合来说,qdrsram可能会更好。综合来看,选择rldram是高密度包,大容量表,低成本 的选择。

  9. 小小牛皮U 于 2010-02-01 10:29 下午

    拜托,RLDRAM做计数器延时太长了。
    100G系统的计数器需要高速率短数据的存取操作,操作与操作之间的延时是有要求的。比如1次计数器累加是1次读+1次写。DRAM的Trc限制了访问速率,做不了高速系统。SRAM的2次操作之间只需要1个时钟周期就OK了。这就是为什么几乎所有计数器都是用SRAM实现的。DRAM一般用来实现线性表,hash表,以及包缓存——高密度,低成本的意义就在此。
    而在DRAM现有的应用中,DDR表现就足够好了,而成本比RLDRAM低的多。看看现在DRAM市场有几家做RLDRAM的就知道了。

    EZchip推出RLDRAM好像主要目的在于用它实现计数器。毕竟从成本上SRAM要贵的多。但是我实在搞不清楚怎么实现的。

  10. 小小牛皮U 于 2010-02-01 10:39 下午

    To 陈首席:Solar2.0还只是一大块画饼。
    100G NPU目前样片的确实只有EZchip一家。但是我非常不看好他的实际工作性能。
    EZ的名气现在是不小,但是做的产品实在不敢恭维。当年NP2就号称20G了,但是到了NP3c才刚刚做到10G性能。现在怎么一下就整出个单片100G的NPU了?华为自研芯片也没这么快的进展啊。
    我倒是看好另一家startup Xelerated,陈首席有空看一下。相较于EZchip的RISC架构,我更看好它的dataflow架构在高性能NPU市场上的应用。

  11. MNSR 于 2010-02-01 11:03 下午

    这里从首席和创始人开始,高手如云,Juniper的系列芯片,尤其是100G,有没有高手可以揭密一下?

  12. system 于 2010-02-01 11:09 下午

    关键这种芯片一年能卖出去几个,大厂都自己搞了(HUAWEI/ ZTE),小厂做不了。

  13. aaa 于 2010-02-02 6:15 上午

    没有qdr接口,tcam只用于acl,不知道packet buffer,stats/policing,ip路由的性能能达到多少,不过可以想象会和吹嘘的100G差的不是一点。

  14. CC 于 2010-02-02 7:34 上午

    楼上,既然TCAM能做ACL,那什么样的查找还能实现不了?

  15. CCC 于 2010-02-02 8:30 上午

    to小小牛皮:1,从它的说明上看,人家明确说了TM和包查找都是DDR3实现,不是RLDRAM,也不是片内;2 interlaken是MAC接口;能否给介绍下做stats时,150M的数据是怎么得到的?

  16. kevin 于 2010-02-02 9:01 上午

    to 小小牛皮U
    Xelerated什么时候成startup了。。。创立了有10来年了吧。。。从x10算也有6,7年了

  17. 小小牛皮U 于 2010-02-02 9:10 上午

    答CCC:
    1. 所有的processor都会采用DDR3实现TM Buffer,这点不会错的。但是我感兴趣的是packet pointer,那个实现会有不同。实现算法会直接影响到实际的TM性能。
    2. NP4采用serial LA接口,即interlaken LA接600M(也许是700M)的TCAM的。请查实。业界还没有这样的TCAM。
    3. 100GE的系统,对应到就是150Mpps。每包仅进行一次包统计不过分吧,这是最简单的统计需求吧,对应就是150M operations per second。如果要同时进行包长统计,就会要求300M的计数器性能。再算上Meter/Policing,会到600M。如果是某些复杂的场合,可能会要求更高。但是对最简单的业务,150M也是最低要求——一般情况下会要求300M。

  18. 陈怀临 于 2010-02-02 9:11 上午

    QuantumFlow的DRAM是RLDRAM。

  19. 陈怀临 于 2010-02-02 9:29 上午

    感觉小小牛皮U是个很专业的家伙。。。最近理客这个死人跑哪里去了。。。难道还真要整的个:掉头一去是风吹黑发;回头再来已雪满白头???客客,你,你,你就这么忍心?:-)

  20. IE 于 2010-02-02 9:45 上午

    MNSR,trio也是类似的

  21. MNSR 于 2010-02-02 10:43 上午

    IE: trio是NP还是ASIC还是什么其他架构?

  22. aaa 于 2010-02-02 4:44 下午

    CC 于 2010-02-02 7:34 am 楼上,既然TCAM能做ACL,那什么样的查找还能实现不了?

    如果我又要acl又要路由呢?bcm的maybe可以用acl同时做,但不知道ezchip可不可以多个acl并行查找

  23. 小小牛皮U 于 2010-02-02 5:58 下午

    to 首席:我可算不上专业,仅知皮毛而已,多谢夸奖了。

    to aaa:不知道NP4 prefer什么样的IPv4/IPv6路由实现?以前的NP2/NP3或者没有TCAM接口(NP2),或者即使有也不好用(NP3,理由不详述),所以是prefer它内部的一个算法引擎的。但是这个算法引擎性能是不能满足线速转发要求的,这个极大的制约了EZChip的芯片性能。——来自Cisco内部未经证实不可靠不负责的消息称,之所以独家供货给C的NP3c能够达到10G线速,一个很重要的原因就是C帮EZChip在NP3c上解决了TCAM接口的问题。当然还有其他的一些原因,不想多说了。

    另外还有一个很大很大的话题:NPU(牛皮U:))发展到更高的速率,难点到底在哪里?为什么ASIC总是很轻易的能够在线速能力上有所突破,而NPU就这么难?而在Router上NPU又是不可替代的。
    曾和一些参与了HW 40G NPU开发的SE聊过这个,有些思路,但是还不很清晰,而且这个话题实在是太大了,超出我的能力范围了,不敢随便大放厥词。

  24. 小小牛皮U 于 2010-02-02 6:02 下午

    to Kevin:没错,Xelerated成立很久了。不过到目前规模还很小,而且又没IPO,我是把它看成startup的。不过我对它的架构更有信心,在高端NPU的市场上,它的架构是能够保证高性能(20G/40G/100G)线速的。目前国内似乎它比EZchip更占优势

  25. 黑猫 于 2010-02-02 8:51 下午

    NP4集成了tm,故牺牲了np处理能力、代码空间和IP查表能力,故它定位是低端低成本。高端芯片是将部件分开,做成不同的芯片。君不见首席发的asr9k的性能测试报告是用1500字节长包,因为短包性能是远不如mx960.

  26. atst 于 2010-02-02 9:16 下午

    to小小牛皮:请注意,NP4的brief_datasheet有明确的说明,interlaken接口是三个可选MAC接口,不是tcam接口;不知道你的150M怎么得到的,按照线速打满,每包操作一次,都是最小包长64BYTE,应该是100G/64/8=195M,而说明上说它的RLDRAM的时钟为533MHZ,RLDRAM的特点是写操作不需要等待,那么533的时钟既意味着533M操作;
    to aaa:TCAM查找当然都是并行的,不分种类的。不过它的说明文档说它的路由查找一般用DDR实现,除非你有特别需求采用TCAM。另外它号称自己的二叉树查找为线速查找;

  27. 杰克 于 2010-02-02 9:24 下午

    号称自己的二叉树查找为线速查找;
    那说明它的二叉树层数固定。

  28. bbb 于 2010-02-02 10:04 下午

    NP4 RLDRAM采用的是SIO的,RL=4延时不会低于250M的QDR II,用SRAM最大才72Mb估计计数器的数量也可能不够用了

  29. 小小牛皮U 于 2010-02-02 10:11 下午

    to atst:关于NP4的TCAM接口,我这里不想再继续下去了。它确实是Interlaken LA,或者你叫他Serial LA interface也可。无需争论,事实如此。
    关于100GE的包速率,你的计算有误,Ethernet包64B在线路上可不是只有64B。当然精确值是150Mpps不到一点,但是一般都是这么说的。

    RLDRAM的问题我不是很擅长,但是很愿意和各位高人详细讨论一下,所谓答疑解惑,皆为吾师。

  30. ilovebgp4 于 2010-02-02 10:23 下午

    To atst

    不能用100G/64/8,以太网帧之间有12bytes的IFG和8bytes的Preamble + SOF,因此一个以太网帧最少要占用64+12+8=84bytes

    100G/84/8=148,809,523.8pps,约等于150Mpps

  31. bbb 于 2010-02-02 10:47 下午

    以250M SRAM为例写延时WL=0 读延时RL=2 533M RLDRAM WL=5 RL=4,一次计数器操作为先读再写,写操作为post,WL的影响可以忽略,关键是RL,533M的RLDRAM延时要小于250M的SRAM,使用的RLDRAM为SIO的也就是读写数据线是分开的与SRAM一致也就是相当于QDR了,唯一有影响的就是RLDRAM连续对同一bank进行操作有个tRC=4,这个就看RP了,冲突概率1/64吧.算下来和250M SRAM差不多了

  32. 小小牛皮U 于 2010-02-02 10:53 下午

    我对RLDRAM的理解:
    RLDRAM和传统的DRAM的区别主要是指由物理上的4 bank变成了8 bank,以及时钟的上下沿均可传输数据,所以极大的缩短了tRC。这也是其Reduced Latency命名的由来。但是即使如此,tRC还是存在的,这是DRAM的本质决定的,只要有tRC,就会影响带宽利用率。
    RLDRAM由于采用了8 bank,所以可以采用Round Robin机制,保证顺序访问不同bank时tRC可以忽略。但是对于随机访问,必须考虑tRC,因为连续2个操作是可能会落到同一个bank上的。
    至于所谓的simultaneously R&W,是指R&W在不同Bank上的。因此对statistics这样的R/W ratio of 1:1的访问并不适用。

  33. 小小牛皮U 于 2010-02-02 11:56 下午

    to bbb:对statistics的读写操作,是sequentially的。因此必须考虑R/W之间的tRC,我的理解对否?
    然后是R/W和R/W之间的tRC。对于statistics这样的随机访问,这也是无解的。绝对不是RP的问题。系统设计时你就得考虑到,你不可能和customer说sometimes wire speed。如果这样的话,WL也是不能忽略的。这样整个带宽的利用率就是20%多——这个计算可能有误,不太会算这个,请指正。
    1次计数器操作对应到2个operation,因此533MHz的RLDRAM只能做到70MHz左右的计数器。
    而且我理解的目前RLDRAM最高到400Mhz吧?
    我认为statistics不可能用RLDRAM实现的,这条路走不通。

  34. bbb 于 2010-02-03 12:41 上午

    对statistics的读写操作,是sequentially的。因此必须考虑R/W之间的tRC,我的理解对否?

    因为是先读再写,重点是什么时候能读回来,写操作是post并不需要颗粒的reply,写的延时是不需要关心的。要考虑tRC的就只有连续的两次statistics的读写操作落在同一个bank上,进一步说就是连续的两个statistics读操作落在了同一个bank。

  35. bbb 于 2010-02-03 12:42 上午

    RLDRAM与DRAM的区别主要就是在tRC,DRAM2 tRC在50多ns,RLDRAM做到了4个tck,能不能做statistics重点是在SIO还是CIO,statistics操作决定了总线上会是频繁的读写互换操作,使用SIO要好很多

  36. 数通人 于 2010-02-03 1:24 上午

    http://www.cypress.com/?docID=9310,这个是cypress的一个SRAM vs RLDRAM的PPT,说的很清楚了。在1:1读写比例下,对于4和8字的突发长度,SIO RLDRAM II可以达到100%的总线使用率,在最极端情况下是50%利用率。所以用在NP的统计上应该是没问题的。况且通过预先设计,可以让容易冲突的表项位于不同的bank来减少冲突的概率。

  37. 小强 于 2010-02-26 1:21 上午

    to 数通人:其实对于RLDRAM能否做counter和meter的问题,我想没有人说他不能做,但这里面的问题是到底能做到什么样的一个效率。EZ号称双工50G,最短以太网报文75Mpps,我们关注的是用RLDRAM一条流在最恶劣的情况下能够做几次counter,又能做几次meter呢?meter需要更多的周期。据我所知一般情况下,一条复杂流需要2次meter+4次counter,我想知道的时候EZ用RLDRAM能否做到这样的需求呢?当然EZ可以说这种情况下他不线速,这也是他们芯片的一贯作风。等到满足他所有线速条件的时候,要么发现这个业务已经简单到毫无竞争力了,要么就发现时间已经过去4,5年了,要么就是用多片级联来完成本该一片就能完成的工作。(不是攻击,只是看到了太多这样的例子了,从NP2到NP3,衷心希望NP4这次不会让大家失望,但是谁又能保证呢?我相信他们自己都不知道,目前看,做不到的可能性更大)
    从技术角度看的话,能不能请各位大侠根据你们的理解计算一下RLDRAM在EZ上可以做到的counter和meter的能力到底是多少?没必要争论能不能做,而是要定量的分析它能做到什么程度。作为系统设计和芯片选型来讲,一个系统工程师关注的是它能给产品带来什么样的竞争力而不是一个芯片能不能做某个功能
    还有就是说用RLDRAM所谓的避免冲突的问题,计数器怎么避免冲突呢?他是完全随机的,你无法预测到下一个报文到底要访问哪个BANK的计数器。如果使用HASH等方法的话,也一样无法保证散列的很开,能否请大侠解释一下用什么样的“预先设计”来避免冲突呢?就算能,我相信也会给设计带来非常非常的难度吧。而使用RLDRAM做统计的唯一一个好处就是多支持一些计数器罢了,但是据我所知X的芯片有至少3种方案来支持百万级以上的计数器。而且设计简单灵活。个人认为用RLDRAM做计数器就算能做也是得不偿失
    再说说X的芯片,至少在城域和路由器的领域里面,我非常推崇,5个人认为比EZ更具优势和活力。那么说说X的计数器,在下一代产品里面他的计数器可以做到非常灵活,而且没有任何限制(因为使用QDR SRAM)。如果用户要支持百万级counter和meter的话,X芯片已有至少3种解决方案,其中也包括使用DRAM的方案。由用户选择到底在乎成本还是设计难度。但是不得不说的是,X的最复杂的那套方案也要比EZ目前的方案设计起来更简单。在这里不方便说太多,有兴趣的同学我们可以私下讨论:)

    呵呵,没有个人感情倾向,不要拍我啊。我就是觉得NPU本身没有好坏之分,设计也没有好坏之分,所有的比较都应该放在某个环境下进行比较。我们选用NPU的时候都要放在系统设计和产品需求的角度评价,单纯说能不能做是没有太多意义的:)

  38. 理客 于 2010-02-26 8:52 上午

    小强很强,问一下:EZCHIP如此不济,为什么C/J都选它,是因为便宜还是别的什么原因?

  39. 阿尔吉侬 于 2010-02-26 7:07 下午

    NPU的counter设计并不是一个难点,EZ不可能连accounting的线速都做不到。
    典型的read-modify-write对外存的首要要求是带宽满足。
    400MHz RLDRAM, 理论上就能做到400M次的accounting 操作 (这里不考虑总线宽度限制,可多片并联). 即使考虑到r/w带宽效率,对150Mpps的业务也能对付。而且EZ似乎有两个RLDRAM接口,带宽又可以double了。
    至于bank切换问题,ASIC设计一般是把相关的counter放在相邻地址来改善性能。因为同一个包总会关联到多个计数器,可以在一定程度上改善带宽效率。
    至于metering,ACL相关的对latency就比较敏感了。EZ真把它放在外存了?我个人不太相信。既不现实,也没必要。这部分占的资源又不大,为什么不用内存?

  40. Gary 于 2010-02-26 9:07 下午

    Huawei的SE认为X比E好啊,看来EZCHIP的Marketing在Huawei没有做好工作.

  41. 数通人 于 2010-02-27 12:52 上午

    to小强
    阿尔吉侬兄已经讲的很清楚了,SIO接口RLDRAM就是为了统计设计的,对于统计的RMW模式,带宽利用率是100%,和SRAM是没有差别的。
    NPU的设计在我看来,一大难点还在QOS。受限于NL的320bit最大字长,做基于IPv6的MQC的时候,光是源目的地址就至少要用去256+8,留给其他fields的bits非常少,无法做复杂的policy matching。假如做IPv6地址压缩,会浪费非常多的表项。还有就是policy class的deny jump问题也是无法解决,25个class,每组3个deny就有3^25的可能,能让ASR1K死循环到没响应,而基于纯软件的7200则没有这种问题。NL基于功耗考虑,短时间也不可能再增加TCAM字长,或者增加内部BANK。反正TCAM这个东东是限制多多,让人又爱又恨啊。

  42. 小强 于 2010-02-27 4:35 上午

    to理客:C和J选用EZ已经是过去的事情了。J已经不用EZ了,除了他们准备自研芯片外,还有一点很重要的就是他们用了EZ后,产品就没有怎么大卖过,饱受诟病。对于C用EZ,前面我记得小小牛皮U已经提到了一点,C承诺帮EZ做了很多改进,而这些是不准开放给其他客户的。而且有非常可靠的消息说C对EZ相当的不满意,说出这话的是非常高的领导。别问我是谁的,您可以通过其他渠道去多了解下。EZ是上市公司,又是美国公司,有些公司用他们的芯片当然可以理解,难道能拿这个东西说事?要看用它的产品有没有成功大卖的,给客户带来什么了。不仅仅C和J,据我所知国内的H和Z以及H3C也有个别产品用过,但是请问哪个公司的产品大卖了?打开他们的单板你会发现上面有4pcs,6pcs甚至8pcs的NPx,这样的产品能大卖才怪。而据我所知X芯片作出的产品现在都是大卖吧。不要说谁用过,要想想用了都是什么样的结果。
    To Gary,恰恰相反,EZ作出的产品性能这么不好,仍然有很多厂商在关注他,仍然有很多同学喜欢他,如各位。就证明他的市场做的很好,如果不是靠市场的话,我想结果完全不是这样了。
    To 阿尔吉农,meter和ACL是两个概念,meter当然是用RAM做的(不管是SRAM还是所谓的RLDRAM),ACL里面存的是是否做meter以及meter ID,真正的meter实现是要靠令牌桶的,也就是RFC2697,RFC2698已经MEF10.1所描述的机制,这是需要用RAM做的。请查证,如果还认为不是的话,我们可以再讨论。还有就是阿尔吉侬大侠说一个周期做一次counter?太夸张了吧?连QDR SRAM都无法做到,还需要2个周期呢,小小RLDRAM能一个周期?请给点专业的理论分析好吗?我学习一下。还有就是再给我培训下一次meter要多少个周期:)
    To 数通人&阿尔吉侬,我的意思是请不要再去说什么能不能做,如阿尔吉侬数哦的400M应付150M没问题之类的描述。我一再说,能不能做根本不是问题,请从业务角度出发,请问2次meter+4次counterEZ如何保证线速?请给个计算公式好吗?我相信大家这么推崇EZ,最EZ的性能计算应该了如指掌吧?非常乐意和大家讨论
    至于EZ有两个RLDRAM接口的问题,请问各位大侠知道X有几个统计接口吗?知道X的灵活度和设计理念吗?我觉得如果大家只知道一个的话,那就不太公平了,比较下才有好坏。
    to all,我上次说EZ用RLDRAM做统计,应该是会选出说支持大量counter和meter (也就是所谓的statics),并且成本低。但是我相信EZ一定用了很多空间换时间的手段,请不要迷信RLDRAM的效率,用起来才知道,如果RLDRAM能用来直接做statistic,各大芯片商早就,说X不用大家可能觉得瑞典人想不到,那请问H的自研芯片用RLDRAM做统计了吗?以前X11可以连RLDRAM,H和Z有用RLDRAM做统计了吗?为什么都用QDR SRAM(甚至DDR SRAM都无法满足要求,效率太低)。所以,EZ如果用RLDRAM就一定是做了很多限制在里面,用的时候会告诉你们的,这是他们一贯的做法。曾经有一个总工级的人物说过,他也不知道EZ为啥用RLDRAM做counter和meter而且完全不知道如何保证线速(应该说是一个正在看EZ的客户,这总改有点说服力吧?难道堂堂总工会想不到阿尔吉侬所谓的400M完成150M?没这么简单的)。如果EZ用了我说的空间换时间的话,那请各位再想想,他所谓的成本优势还有什么?一个576M的RLDRAM和一个36M的QDR SRAM比,成本可想而知。而且再加上设计的难度。设计成本,维护成本不算吗?
    to 数通人,你说的ACL问题,的确是这样的,但是现在IPv6的应用并不广,而且IPv6的ACL规则也没有什么定论,也没有说一定要用IP的全字段做ACL,这还是一个很久远的事情呢。而且ACL的实现方式本来就有很多。有的是L2-L4的ACL有的是用L2或L3或L4的ACL。我相信就算用IPv6的IP全字段的话,也可以用L2或L3或L4的ACL。这些需求的明确需要很长的时间,而且客户需求之上,客户会在性能,功能,成本之间做权衡的。而且TCAM达到640bit或者480bit以后也会是一种确实的
    不是要与大家为敌啊,是想讨论,多向各位大侠学习学习,请多指教

  43. 小强 于 2010-02-27 4:50 上午

    原来说两个接口问题的是阿尔吉侬不是数通人,不好意思啊。
    还有一个阿尔吉侬说的meter要用内存的问题,呵呵,请您查实。首先我觉得您可能搞错了meter的概念吧?我想问问EZ的内存有多大?客户对meter的需求又有多大?怎么可能用内存?而且meter还就是用外存来实现的。
    对于ACL,EZ有个Tree算法,但不是证明他用内存完成的,还是那个问题,他的内存有多大?你的ACL需求是多少?好好计算下再说。说到Tree算法,又有好多要说啊。用过EZ芯片的人都知道Tree不用则已,用则线速必失(我说的是在做ACL等大Key值和IP等大规格表象的时候)。以前NP2和NP3是不能外接TCAM的(不能说不能接,是接了就有一个10G口不能用,共享PIN的),他们一直号称他们的Tree很牛,“忽悠”了多少客户。最后客户一用,脸就长了。才发现根本不是那么回事。所以就优化再优化,压缩再压缩,最后还是要多片级联来完成本该一片能完成的工作(因为一开始宣称的老好了!)。如果他的Tree很好的话,我想问问他们为什么在NP4的时候增加了TCAM接口,别增加不就得了吗?所以阿尔吉侬大侠,请重新审视一下你的内存说法吧。不知道您的不现实也没必要是基于什么得出的结论啊?您用EZ设计了几款产品?用X设计了几款产品呢?
    还是那句话,不要定性的说,咱们都专业点,拿数据说话,说出来能做多少,怎么做的,效率多少,这样的讨论才有意思,否则就变成争吵了,就没劲了

  44. 陈怀临 于 2010-02-27 8:06 上午

    小强,你确实很强。你的评论其实就是一篇非常不错的文章。你能否把你的工作和(或)学习的一些知识经验写下来成文,帮助弯曲评论,帮助社区,帮助中国?

    谢谢,

    陈首席,

  45. 理客 于 2010-02-27 8:26 上午

    小强的专业很强,佩服。那是不是可以这样理解:C/J选择EZCHIP是个错误?能否再分析一些为什么C/J这么强,怎么犯了这么大的错误?

  46. 陈怀临 于 2010-02-27 9:16 上午

    线速 与 DRAM带宽的问题:

    我的理解是,一个芯片或系统的Packet Mem的带宽应该是 6x的Traffic的Rate,系统才能确保线速。

    否则,好像有问题。。。这也是为什么NP里往往有多个Memory Controller。。。。

  47. 数通人 于 2010-02-27 9:37 上午

    to小强
    不好意思,现在玩的是20G的接入设备,我们的NPU用的还是RLDRAM做统计,所以也没觉得非要QDR SRAM不可。不过经你一提醒,在100G的环境下,确实统计也会成为一个瓶颈。可能真得要SRAM或者很多个DRAM控制器来实现。暂时没机会玩NP4,手里也没有它的DS,所以也不敢妄下结论。
    EZchip的好卖除了会做市场外,也许也和Ran Giladi的那本书有些关系吧,开放了构架信息,也同化了TX们的思想。至少暂时EZ的100G是独此一家sample,HX还得再等等,后面还有TPACK加入战团。至于HW和J弃用EZ,除了性能上的考虑,个人觉得也有EZ和思科走的实在太近了(主要是9K),怕EZ变成下一个Greenfield的考虑吧。
    IPv6的QoS的确不是什么很久以后的问题了,ASR1K的DDTS库里已经有相应的CFD了,客户对QoS的需求总会超出程序员的想象,policy-class能配啥,客户都敢配。而且IPv6的next header机制也不那么好玩。

  48. 小强 于 2010-02-27 6:55 下午

    to 陈首席:我可不强,可能是说的“嗓门”大了点,给大家带来不好的感觉请多原谅啊。对于陈首席说的packet mem要是packet rate的六倍以上,我不太确定明白了你的意思,您指得packet mem是包存储还是只表项存储还是专指最近大家讨论的counter和meter啊?如果是包存储的话,这个好像不太对,由于包存储一般只有一次读和写,至于微码处理所得到的各种信息都是存在内存里最后统一修改报文的,所以不需要6倍;如果是表项存储的话,那么6倍显然是不够的,因为线速的评估是根据最长流程来设计的,一般最长流程对外存表项的查找需要15次以上,而且还要根据数据线的宽度来计算周期,如返回值是64bit的表项一个周期,返回值是128bit的表项要两个周期,以此类推等等,所以基本上算下来,存储表项的外存的读写效率应该在26x包速率左右(最复杂流程);如果是针对meter和counter的话,6倍应该也不够,拿QDR SRAM来讲,一个counter需要2个周期,一个meter需要4个周期,最复杂的2个meter+4个counter为例的话,需要16个周期左右。当然有些芯片厂商会做一些优化,如X,他们不需要这么多。
    我不知道首席说的跟我说的是不是一个问题,写了点个人意见,见笑了

  49. 小强 于 2010-02-27 7:07 下午

    to 理客:我觉得最好不要这样讨论,没意思。咱们都用数据说话行吗?不过我倒是可以针对您的问题说几句。
    C和J是不是犯了很大的错误我不能评价,谁会承认自己错了呢?但是错不错,只有里面的人自己心里清楚。今年有个同事跟我说,他回家想给他爸买瓶茅台,但是发现很多茅台都很贵,后来发先茅台醇挺便宜,他就买了(他以为这也是茅台),可是回家别人都说这不是茅台,但是他会告诉所有人他买错了吗?他还是坚持说其实还是不错的,口感还可以,等等。就好象卡片机里本来佳能的非常好,但是由于索尼的外观让你觉得很好,你就买了,后来发现性能不行,就连存储卡都不能和别人共享的时候,你会承认你买错了吗?你依然会说,其实外观还是很时尚的。您问的这个问题太不专业了。
    上面是用不专业的方法来回答你的问题,下面举几个例子。
    C和J是否失败,我不多说了,因为我说多了,您也查证不了,我相信您的渠道不够多,否则我前面已经说了,C公司的非常高层领导已经很愤怒与E了,您为什么不去考证下?还来问我这个问题?我说几个国内的吧。我说了国内有几个公司的几款产品用过E了,但是据我所知,现在已经有至少3个产品主动考虑更换到X了,虽然有的由于进度问题,需求迫切程度问题等更换速度不是很快,可能直接切换到下一代也就是HX。但是不能不说现在很多已经无法忍受E的芯片了。我想您的能力应该可以验证到这些信息吧?您用在这质问我的时间去多调查下岂不是对大家更有帮助?
    还有啊,C和J是很强大?但是请看看趋势吧,好吗?强大是因为E变得强大吗?J已经在走下坡路了,C的强大目前看毋庸置疑,但是主要是他的标准主导,产品前瞻性,客户忠诚度等等吧。而且C根本靠的就不是商用NPU打天下,他们有自己的芯片。所以就算E选错了,对他们根本没有任何创伤。我始终相信H和Z会慢慢强大起来,C曾经说过H是他们21世纪唯一的竞争对手,请不要再说C和J有多强,不要妄自菲薄

  50. 陈怀临 于 2010-02-27 7:18 下午

    咔咔咔,小强强好样的!:)就是要给客客hard time…

    是的,ezchip会淡出c和j.edge上ez确实不够了。但enterprise products还是很大的。。。

  51. 小强 于 2010-02-27 7:26 下午

    to 数通人:原来是个误会啊,这里面谈论的都是100G芯片,所以我没想到您再说20G,不好意思,语言上有些犀利请见谅啊。其实我还是那句话,我没说过EZ用RLDRAM做不了100G的meter和counter,只是觉得他可能做不了多少次,会在复杂业务的时候成为线速瓶颈,我也希望有大牛给大家解惑一下,说明EZ的统计不是瓶颈,大家学习下:)
    其实EZ的架构和以前的Rainer以及2800的架构都有比较相似的地方,各大厂商接受起来比较容易,而且EZ有了自己的改进,所以开始更容易被人接受,尤其是底层工程师。而X的芯片是流水线式的,连包缓存都不需要,恰恰是他的颠覆性的架构给他带来了只要业务排开必线速的巨大优势,同时也恰恰是这个颠覆性的架构不太容易说服客户去接受他。加之公司小,没有上市,等等所谓公司级风险一直被对手打压,客户也必然会受影响。而且在07年的确经历过一段最困难的阶段,加之那个时候他们的中国销售团队刚刚成立,很多东西不系统,让EZ钻了不少空子。可是事情就是这样的,你可以在别人虚弱的时候钻空子,但是你钻了空子只是争取了一个证明自己的机会,当你把握不住的话,大家的眼睛是雪亮的,你一再让你的客户,尤其是当年选你芯片的人在仕途上折戟沉沙,那你必然要被替换掉。太多的就不多说了:)
    说到HX的进度问题,这可能是EZ的NP4现在在市场上没有完全败下来的唯一理由吧。其实根据可靠不能再可靠的消息是HX会在E的一到两个月后sample,这个时间并不算长,很容易被接受,只是X以前的进度延了太多次了,导致现在客户连这个最可靠的消息也不愿意轻易相信了,所以才会同时关注下E,尤其是在商务上,各个公司不可能只看一家,否则商务太被动。但是胜败会在HX出来后,各家公司选型结果出来后有所定论的。
    其实也有很多公司怕X成为下一个Greenfield,这是E一直在客户那边打压X的唯一一个把柄,因为X小,而在产品方面E基本找不出X任何缺点。尽管曾经有X的员工去了E,但是仍然找不出缺点,从来都是从商务上进行攻击。不过如果X公司的人看到您的帖子后,以后也可以在客户那边打压一下E了,呵呵,你内X公司提供了一个思路啊,他也有可能成为Greenfield啊:)
    至于ACL,您说的是对的,客户的确啥都敢用,只要有人能做出来,这也正是为什么各个厂家都在追求新特性的原因,这个我同意。我还是那句话,最终的运营商在性能,功能,成本上做权衡的。而且针对IPv6的ACL,各大TCAM厂商一定会出480bit或640bits的TCAM的。

  52. 小强 于 2010-02-27 7:42 下午

    to 首席:多谢您的权威性总结。没错,enterprise prudct是很大。而且企业网对线速没啥严格的要求,要求的是业务全。所以EZ的低性能在企业网上看不太出来,或者说可以勉强接受。
    因为您的这个帖子中有一句话“NP4芯片的定位是在城域网(MAN)为主要市场,具体产品方向为Carrier Ethernet Switch和Router等”,据我所知,城域以太网和企业网在各个公司都是两条独立的产品线。所以我主要是不认同他在城域以太网交换机和路由器可以跟X相提并论。
    对于企业网,只能说X和E各有千秋吧,其实E能做的,X都能做。以前的X11有一个弱点就是要么所有业务线速,要么所有业务都不线速。这就导致了有的业务客户可以接受不线速,但是有的业务必须线速的需求无法满足,而NP3刚好可以,因为他压根就不能保证所有也无权线速。但是X即将推出的HX和AX已经解决了这个问题,他可以根据业务的不同类型来决定业务是线速还是不线速,要换回还是不换回,不仅仅如此,他们还有专门的调度机制来调度保证线速的业务和不保证线速的业务,充分的保证了资源利用率。并且使得产品形态更合理。而且据我所知某超大公司的某企业网交换机已经评估过了HX和AX,并且决定等待HX出来了。所以说在企业网级别,H和E的一场斗争就将展开。而且我依然看好H,因为实在不知道E哪方面可以赢X,或者哪位大侠知道可以给小弟指点下:)
    说到X相对于E的弱点,有一个就是X只能解析处理报文的钱256字节,而E可以全解析。但是在城域网和企业网里,256字节足够了。这也不算是啥缺点
    这里我还说到了一个AX,据我所知AX是针对PON和接入交换机设计的产品,因为以前X在这个市场上没有关注,现在他们的AX横空出世,准备和各个接入市场的对手们较量一番,当然其中包括很多很多对手,NPU领域的对手也包括E。但是有于AX真的很强大,所以很多以太网交换机以及OTN的设备都可以用AX,很多厂商都在关注。AX尚且如此,更何况HX。
    我关注X和E的芯片可以追溯到4年前了,我一直觉得他们都很不错,但是非要比较下的话,我认为X完胜E,当然话说的有点死,但是至少在我看到的领域,我设计的产品的领域里面看X完胜

  53. 陈怀临 于 2010-02-27 8:07 下午

    很好奇的问,小强强是哪个部队的?感觉不是广州军区的。。。这也太狠了吧。难道是成都军区的?

    唉,我最后(已经)只能以德吸人了:-)。靠才是不灵了:-)。大宋为何这么多人才。。。我是又高兴又嫉妒。。。高兴的是我大宋复兴有望;嫉妒的是好像没我什么事。。。:-)

  54. ABC 于 2010-02-27 8:54 下午

    首席啊,关注方向就行了,大方向没问题,至少保证不会失败!细节方面永远是长江后浪推前浪啊。

  55. 理客 于 2010-02-27 10:04 下午

    小强同学,感谢回复,我是来学习的,对您的发言都能理解,我拿不出具体技术分析数据。没有任何challenge您的意思,您误会了,因为这是我的外行,我也基本上没有更多的渠道。您太谦虚了
    希望EZCHIP方面也有强人来challenge一下我们的小强同学,还是已经被PK得此时无声胜有声了:)
    C在某种程度上在向下走,H确实也在猛追,鹿死谁手,拭目以待

  56. Multithreaded 于 2010-02-27 10:47 下午

    没想到现在还有NPU的粉丝,在这里讨论X和E的关系。刺激一下小强同学!

    X的产品随好,但有多少人会在流水线上用汇编编程哪? 玩好一个100多级的流水线可不是一件容易的事。

    从市场的角度,E和X都没戏。C&J都有自己的100G的芯片,只有H&Z的一点市场。最有潜力的是Intel IXP-2400类似的东西,在无线的接入层上。

  57. 小强 于 2010-02-28 3:34 上午

    to 首席:我是志愿军:)

  58. 小强 于 2010-02-28 3:46 上午

    to Multithreaded:NPU自然有他有魅力的地方,就连不会唱歌的人唱出五音不全的歌都有数不尽的“歌迷”和粉丝,更何况还有很多可取之处的NPU呢?
    还有就是您说的100多级流水,此言一出,就知道你完全是个外行,至少对X的流水线结构完全是个外行,外到十万八千里了,请问您的100多级流水是指什么啊?小强不才可以跟您讨论下,呵呵
    从市场上看的话,您说对了一半吧,C早就有自己的芯片,这谁都知道,可是他的NPU不是很强,当年收购Greenfield也是出于此原因,可惜Greenfield实在不行,他现在还在寻求和商用NPU的合作,X和E都有很大的机会,只是E先走了一步,但是我也说过现在里面对E也很不满意,所以X也是机会很大,现在鹿死谁手还不清楚,当然里面还有很多政治因素了。当然我也说过,C不会让NPU占他太大的比重的,但是NPU一定要有,NPU相对于ASIC的优势不用我絮叨吧?大家都心里清楚。敢问现在哪家大公司不用NPU?商用ASIC和FPGA都无法满足业务的灵活性和新需求的爆发式增长。对于J的自研芯片,我们只能拭目以待了。
    我再补充您两句,不仅仅C和J,H和Z也在做自己的NPU,而且不久您可能就会听到更多的消息,但是这又能说明什么呢?能说明X和E没机会了吗?NPU做出来,一版成功的从未有过,万事需要时间的积累的。
    有一点我赞同,现在NPU的市场被压缩的很厉害了,正所谓适者生存,E和X也在积极转型中。
    您所谓的2400在无线接入,没错,还有LSI(Agere)的芯片,他们是走介入路线的,接入的量永远是很大的,这是必然。但是并不是说只有他们有优势。您研究过E和X在接入市场上的动作吗?
    我前面的帖子已经说过了,尤其是X现在正在面向接入市场,尤其是PON,现在PON都在考虑转向NPU,现在的问题在于NPU和PON MAC的合作,新的战场已经硝烟弥漫了。您的X和E都没戏的结论似乎停留在2年前了吧。感觉不能说您说的不对,但是的确觉得说的差强人意了。

  59. 小强 于 2010-02-28 3:48 上午

    to 理客:其实我也是想学习的,就是想大家都用各自知道的专业知识共同讨论共同进步。:)不吵不相识。马克思和恩格斯当年也是吵到差点动刀子,但是人家是无产阶级战士,创造出了最牛逼的哲学。争吵出哲学:)

  60. Multithreaded 于 2010-02-28 8:20 上午

    In general a pipeline consists of a numer of pipeline stages. X’s product may have several pipelines and each pipeline has more than 100 pipeline stages.

    A user needs to program these pipeline stages to make it work.

    10 years ago, there was a fight between pipelineed archtecture vs. RISC in NPU. The programming difficulty of the pipelined architecture makes X’s product hard to understand and maintain.

    When you discuss NPU, please think both ways HW and SW. Every NPU company can make HW, be it 10G/40G/100G, even though it is very challenging. The real issues come from SW. I.e. how to program this type of monster. That is the exact problem Intel faces right now. Who knows how to program multi-core?

    就知道你完全是个外行的评论是否下得太早了?

  61. 理客 于 2010-02-28 8:25 上午

    04年曾建议过NP+ASIC,可能当时技术发展还不够,当然,老大们估计也早就考虑到了,无需小人物的大建议。
    目前多核江山也是一片火,把多核和NP组合成一个类似山寨的通用方案,也许能做点事,对于更有专业追求的公司,还可以在此基础上加上自己的专用ASIC,就更完美了。当然具体到系统架构,涉及到成本、功耗和散热等诸多问题,就不是那么简单了
    J的自研NPU指的是TRIO还是另有所指?

  62. Multithreaded 于 2010-02-28 8:32 上午

    >我再补充您两句,不仅仅C和J,H和Z也在做自己的NPU,而且不久您可能就会听到更多的消息,但是这又能说明什么呢?能说明X和E没机会了吗?NPU做出来,一版成功的从未有过,万事需要时间的积累的。

    So what? I knew the story of H brought their first generation NPU in 弯曲。The real difficuly is from SW. In this case, H can not make the OPEN64 compiler work :-(

  63. 陈怀临 于 2010-02-28 8:32 上午

    小强倒是没必要说MT是个外行。。。:-)。弯曲评论的水比较深,IEEE的张Fellow也在这里混呢。没准MT是个什么公司的大牌,或者某个学校的兽兽。。。:-)

  64. 陈怀临 于 2010-02-28 8:49 上午

    从技术的角度,我相对同意MT的看法。我也大概知道你是谁。是,我回来后与你吃饭,见面。

    是,硬件微结构一定,其实事情相当稳定下来了。软件的变化太大了。。。

    据说Intel fail掉的那颗GPU,就是(埋怨)软件做不了优化:-)。

  65. 老刘 于 2010-02-28 4:05 下午

    MT口气有点大,说话有点绝对,这也难怪别人说你外行。
    NP短期内不会消失嘚。不是每家OEM都能像Cisco,HW那样牛逼。请记住,华为海思过年那阵license了Xtensa处理器。接下来你们也知道干啥了。
    回理客,多核和NP集成嘚SoC有了。LSI ACP34xx….

  66. 陈怀临 于 2010-02-28 4:44 下午

    小强估计是广州军区的,或者就是广州军区做大辽办事处的。。。

    据我不愿透露来源的消息透露:–)

    华为最新的NE,CX的线卡 ::= Dune Fabric + X11 NP。

    While,

    ME 线卡 ::= Dune Fabric + EZ

    再晒晒? 好,大元宵的,不晒有损人品:-)。

    LPUF-20/21 card
    =1x20G X11 + 1 FAP20v

    LPUF-40 card
    =2x20G X11 + 2FAP20v

  67. 小强 于 2010-02-28 6:26 下午

    to 首席:我真是志愿军,哈哈
    您晒的还少了点,不仅仅如此,HW里面还有产品用X11而且是出货量最大的,您给漏掉了,应该再调查下:)
    ME已经有意换掉EZ了
    对于说MT是外行,我在这里道歉了,倒不是因为我觉得我的判断依据有错,而是觉得不该这么攻击他人,诚挚道歉

  68. 小强 于 2010-02-28 6:39 下午

    to MT: 我还是需要直接跟您说句对不起,我的攻击性言辞是不对的。
    但是您摆了一堆英文上来,一我看不懂,二您觉得这是权威的吗?100多级编程,您知道是指什么吗?我相信您知道,否则也不会这么理直气壮哈。100多级编程其实就是100多条微码指令而已。只用100多条指令就可以完成最复杂的业务,请问编程还有比这容易的吗?所以您说因为100多级编程就导致了X很难理解和使用,这让我觉得您一开始是“外行”。
    我来说下X对设计的时候要求最高的地方在哪里吧,是因为他的PB模式,因为每个PB有32条指令(HX是16条,就是为了解决这个问题的),32条指令后就可以进行查表(这是相当灵活的),但是有一个问题,当一开始设计的时候流程已经写死,加入写了30条指令,但时候来发现要在那次查表之前增加3条指令,30+3>32,这样就导致需要将流程重新排或者将流程顺移一个PB。这要求在一开始系统设计的时候要有一个NB的人来做总体把关。将以后最有可能出现需求增加或者目前需求不明确的地方,做多一点的指令预留,因为X11完成所有业务还是有资源预留的(HX和AX会有更多的资源富裕),这是X的PB架构的唯一的需要多加注意的地方。而不是他的流水线的100多级流水。所以我说写这个文章的稍显“外行”
    我举一个例子,以前有一个某国内超大型公司的一个产品从其他的NPU切换到X,开发工程师一开始很抵触,害怕不会用,可是后来居然说,这是他们遇见的最好编程的NPU,一个人,3天就可以将IP最复杂流程编完并调试通过(当然他已经很深入的学习一段时间了)。所以后来给他提心需求的时候他都是欣然接受,而不是像平时大家想想的那种推脱,因为他说改起来太容易了(不过说句实话,我也觉得他有点自残,呵呵)所以别说100多级流水,听起来怪吓人的,您说100多条指令就直观了
    P.S.我再强调一下,因为我发现可能是我写的比较多,每次我写的信息都被跟贴的同学忽略了很多。如果前期设计不当,X的维护可能会在极端情况下,让人觉得不是那么爽。但是只要你前期设计做得好,万事OK。而且HX和AX已经改进了,每个PB有16条指令就很好的解决了指令碎片问题

  69. 小强 于 2010-02-28 6:43 下午

    to 理客:现在很多公司尤其是我们国内的那个大鱼两年前就已经用了X11+ASIC的做法了,难道这是您4年前的大建议起作用了?:)哦,这么说来的话首席晒的还是不全,还差了好几个呢
    而且现在这条大鱼的其他产品的新班子也有X+ASIC的做法。当然不是X自己搞不定,加ASIC是因为要降成本。一定有同学问难道X+ASIC会比单独的X便宜吗?嘿嘿,还就是便宜,至于其中原委我就不道破天机了,想知道的人自然会通过他的渠道去了解的:)

  70. 小强 于 2010-02-28 6:50 下午

    再to首席和MT:没错,很多NPU代码的优化是相当困难的,当年H在2800上优化代码做了大半年。这就是血的教训。而E公司的芯片由于性能的问题,几乎没有一个设备上用了之后不花大力气优化的,这也是他的弊端。而我似乎没有听说过X11需要怎么大规模优化的?X11一个流程下来20G线速的情况下,全流程最多640条指令(其实不是MT说的100多条,所以我才会觉得那个结论有点道听途说),640条指令能需要怎么优化呢?所以X更趋紧与ASIC,他只需要不难的几条微码就可以实现业务的灵活了。这也是我推崇他的地方。
    没错ASIC不需要对转发编程,只需要驱动,但是我说了ASIC的弊端大家都知道,业务不能修改,灵活度低无法应对需求的爆发式增长,大公司一定要用NPU,至于是用自己的还是商用的,那就看谁NB了。自己的好当然用自己的,但是前提是自己的要好
    所以从大家关心的软件角度出发的话,我又要再次推崇一下X了,呵呵

  71. 小强 于 2010-02-28 6:52 下午

    to MT,你的信息有点慢了,虽然我不知道您是谁,看首席都要和你吃饭,您应该是个人物,但是我说的不是他的第一代NPU。多说无益了,您再调查下。跟软件无关。
    我还是那句话,NPU比ASIC是有优势的,短期内没有消失的理由,无外乎就是用谁的而已

  72. 小强 于 2010-02-28 6:55 下午

    to 老刘:您虽然短短几语,但是我fully agree

  73. test 于 2010-02-28 7:46 下午

    to 66楼 陈首席,

    FAB20v 应该是FAP20v吧!

  74. 理客 于 2010-02-28 8:00 下午

    老刘:LSI ACP34xx….大体能力和前景如何?
    小强:我不是这个专业,04年瞎扯的几次,应该没人理
    NP的代码空间目前看看不到好的解决方法,唯一商用的方案就是加ASIC。
    因为IP太灵活变化太多太快,这个对要求设计做许多更多巧妙的后向考虑的问题,不是一般的难解决
    J号称的的programmable ASIC如何?

  75. cs-cisco 于 2010-02-28 8:05 下午

    说思科走下坡路的话未免过于唐突了吧,我相信鲑鱼会跳过瀑布去产卵的。呵呵。

  76. 小强 于 2010-02-28 11:06 下午

    to 理客:现在新一代的NPU在指令空间上已经有很大飞跃了,如X的下一代的最长指令空间增长了近两倍。所以指令空间不是问题。当然是否够用还要看路由器把最复杂的业务放进来的评估结果,目前做过评估的都没有问题
    可编程ASIC只是一个噱头,既然是ASIC他能做的就是尽量增加点灵活性而已。我还是看好NPU在灵活性上的优势,只要NPU能够很好的解决他的劣势。

  77. 理客 于 2010-02-28 11:17 下午

    小强:如果没有ASIC完成基本的业务,全用NP完成,对于一个全业务的智能路由器而非功能相对单一的L3设备,恐怕再来两倍的空间也未必够,两种方案:
    1、把ASIC的功能尽可能多的集成到NP中去,简单的调用而不必用很多微码,可能目前已经有在这样做了,这个不知道在技术上有何限制,肯定有问题,否则早就发展得很快了
    2、license控制,这个也会很烦
    J的programmable有噱头的成分,但J的做IP的ASIC能力,在业界可以算第一吗?

  78. Multithreaded 于 2010-03-01 12:00 上午

    >MT口气有点大,说话有点绝对,这也难怪别人说你外行。
    NP短期内不会消失嘚。不是每家OEM都能像Cisco,HW那样牛逼。请记住,华为海思过年那阵license了Xtensa处理器。接下来你们也知道干啥了。

    这也正是独立的NPU公司做不大的原因。 每家都有自己的NPU,有谁会真心地用别人的NPU哪?

    我曾经为NPU事业贡献过”青春“,真不希望大家被MARKETING的人给吆呼了。用NPU做那些L2/L3的东西没有什么高深的,都十几年过去了,应该不难掌握。

  79. Multithreaded 于 2010-03-01 12:14 上午

    >我来说下X对设计的时候要求最高的地方在哪里吧,是因为他的PB模式,因为每个PB有32条指令(HX是16条,就是为了解决这个问题的),32条指令后就可以进行查表(这是相当灵活的),但是有一个问题,当一开始设计的时候流程已经写死,加入写了30条指令,但时候来发现要在那次查表之前增加3条指令,30+3>32,这样就导致需要将流程重新排或者将流程顺移一个PB。这要求在一开始系统设计的时候要有一个NB的人来做总体把关。将以后最有可能出现需求增加或者目前需求不明确的地方,做多一点的指令预留,因为X11完成所有业务还是有资源预留的(HX和AX会有更多的资源富裕),这是X的PB架构的唯一的需要多加注意的地方。而不是他的流水线的100多级流水。所以我说写这个文章的稍显“外行”

    这个正是我说的编程难点。 如果那位大牛离开了公司,代码如何维护?一级放不下,岂不是要长江后浪推前浪的来个大改动?

    请回顾一下,软件维护所占的工作量要远远大于开发的工作量。每级预留提前量的做法是不得已而以, 不是一个软件开发的好方法。

    我说100多级就是这个PB. 也许最新的X产品有改进。但本质上这种流水线的编程方式不是一个好地编程模型。

  80. 小强 于 2010-03-01 12:29 上午

    to 理客:这里面有一个问题您可能忽略了。那就是全业务职能路由器是否需要所有的业务都线速。
    分别讨论下:(我这里就以X的HX举例了,当然也希望比我更熟悉EZ的兄弟们站出来用EZ举例哈,很想多学习下,期待大侠指教)
    1、目前我看到的一些接入层面的路由器,他们把全业务摆进HX是基本没有问题。当然X11是放不下的,这也就是首席在66楼晒的几个产品之一了。
    2、如果您说的是更高端的话,那么要考虑是否要求所有也无必须权线速
    2.1、需要全线速,那么ASIC+HX或者2×HX是很好的选择
    2.2、不需要全线速,如最复杂业务可以不线速,那么1×HX就足够了,因为我前面的帖子说过了HX可以支持部分业务转圈(也就是可以用更多的转发资源,多转一圈就会多用一倍的资源,如指令空间,各种引擎等等),不仅仅支持转圈,还支持线速业务和不线速业务之间的调度,非常灵活,所以1×HX就足够了
    其实前面说的都是基于1片搞定所有业务线速的前提的,其实当需求拿来的时候,任何设计都可以灵活考虑,咱们是高新技术行业吗,呵呵,一成不变哪受得了,否则不就是MT所说的没什么高深了吗,哈哈
    其实现在有很多设备商在对运营商宣称不需要所有业务都线速的理念了,在这种情况下,业务的灵活度是最重要的,NPU的灵活优势一览无余
    总而言之,具体问题具体分析

  81. Multithreaded 于 2010-03-01 12:33 上午

    >>再to首席和MT:没错,很多NPU代码的优化是相当困难的,当年H在2800上优化代码做了大半年。这就是血的教训。而E公司的芯片由于性能的问题,几乎没有一个设备上用了之后不花大力气优化的,这也是他的弊端。而我似乎没有听说过X11需要怎么大规模优化的?X11一个流程下来20G线速的情况下,全流程最多640条指令(其实不是MT说的100多条,所以我才会觉得那个结论有点道听途说),640条指令能需要怎么优化呢?所以X更趋紧与ASIC,他只需要不难的几条微码就可以实现业务的灵活了。这也是我推崇他的地方。

    H用了IXP2800里面有8000条指令还叫不够用。640条能做啥?这十几倍的差距令人琢磨?

    1). How to do IPv4 forwrding in general in X?
    2). 是否难得操作都用TCAM?
    3). Is X instruction a VLIW type?

    In general NPU optimization is hard. pipelined based optimizations are even harder. That is the reason that avoiding pipeline programming as much as possible.

    In a word, there is always a way to manually tune NPU to its peak performance. However one has to consider how to maintain the peak performance when anew change request comes in the future.

  82. 小强 于 2010-03-01 12:38 上午

    to MT:您作为一个为NPU事业奉献过青春的人,现在应该是个牛人了,这点我深信不疑。那您一定不难了解到现在都谁用X11了吧,您能顺便了解下他们谁在大改或者整天优化代码吗?因为我一个人说很难有说服力,您调查下咱们再讨论:)。
    对于您说的牛人离职,这是不怕,据我所知有一个大用大卖X11单板的产品,当年负责架构设计,芯片选型,产品前期开发的牛人经过几年的洗礼,全都各奔前程了,但是他们依然是业界最牛的XXX产品。从未大改过。其实流水线架构,只要初期留的好,后面基本不用改,所以不怕大牛离职,只要大牛开始在设计就OK了
    您说的这个流水线的编程方法,从X11出现的那天起,就不停的被人challenge过,天天的问,总是怕这那,可是怕的人最后都没用,用了的人都说好。这也就是说怕的人丧失了一个机会(有点绝对哈,相对的),而选了更头疼的东西。我相信MT应该是属于没有用过X的大牛吧。如果您用过的话,我想您不会这么说了,我不才,用过一些。
    其实所谓的编程困难都是理论上的一种畏惧感,设计起来其实没有。如何避免和解决这个问题,我前面已经说过解决方法了,MT大牛是不是觉得我的那个方法不好?或者您觉得那个方法很难理解和被使用呢?我遇见过很多人,都为产品前期的设计如痴如醉,那是最锻炼一个人的时候,其实没有那么可怕了。用一下,给别人一个机会的同时也给了自己一个机会:),请不要停留在理论阶段,理论是把双刃剑啊

  83. 小强 于 2010-03-01 12:47 上午

    to MT 81楼:看来您真不是内行,我有点小崩溃,难道所有的东西我都要解释清清楚楚吗?您也觉得640条指令很奇怪是吗?我相信所有人都会很奇怪,可是我咋就没想到您会认为这是总指令空间呢?
    我虽然没有明说,可是行家一看应该知道我在说什么吧?可是我说了全流程或者最复杂业务等等了啊,我还以为您真了解流水线机制呢。我说的640条是单流程最大指令,不是整个的指令空间…..
    还有就是,X的指令有merge功能,我不需要再培训下了吧?就是可以一条指令merge四个不同的操作,真正的操作数平局下来是2倍多于640的。前提这是20G线速,如果10G线速的话,指令空间更多。
    X的指令是VLIM
    对于您说的NPU总是宣称最高性能的问题的话,我觉得很多NPU是这样的,但是出X外,X在这点是他独步江湖的地方。当然别太离谱的需求,太离谱可以有N种方式,我在给理客的回帖中写了,您可以帮我review一下,欢迎讨论
    P.S. 能不用英文吗?看起来费劲啊

  84. 小强 于 2010-03-01 12:53 上午

    再to81楼MT:一个general IPv4如何放到X11里面,这个问题,您调查下行吗?我相信您的实力。这都多少人做过的了,咋还怀疑呢?这不是新片子啊。
    HX的能力较X11有了大幅提升,并且功能有了突飞猛进的提升,我想您调查过X11后,就不用再问HX了吧
    复杂业务都放在TCAM里?您的这个构想我真是从来没敢想过啊,TCAM是要连在NSE接口上的(目前ASIC和NPU的主流连TCAM的接口),NSE也是有频率的,有performance的,保证线速情况下,一个报文能访问几次?你可以计算下,TCAM分288bit和320bit两种,320bit的效率更高。20G线速下,现在返回值为160bit的,最多就能返回8次,320的最多返回4次。复杂的都放TCAM里这个构想太crazy了,这样的系统能线速我就服了,我的确没想过….

  85. 小强 于 2010-03-01 1:02 上午

    再toMT:不好意思,光顾回您的技术贴了,一时忽略了您的中心思想,您到底想说啥呢?是NPU赶紧滚出历史舞台还是您觉得我对X和E的比较有觉得不对的地方呢?如果是NPU要消失,那您觉得什么东西来替代呢?短期内的哈,我相信无穷远的将来一切皆有可能

  86. 小强 于 2010-03-01 1:16 上午

    to MT, 想了想,我可能言辞有点激烈,再道个歉。我说话也有点决,哪有什么产品会不优化呢,不管用啥都会优化下的。只是时间长短吧。
    由于HX支持了区分业务转圈,以后就没有您说的那个问题了,对于X11的话,我相信有人优化过,但是没有您说的那么严重吧。相对于其他的芯片来讲,无论是多核还是以前的2800,rainer,2400等都应该好很多。

  87. Multithreaded 于 2010-03-01 1:22 上午

    小强同学,能不能不扣帽子?你有喜欢X的癖好,我可以有不喜欢X的自由。

  88. 小强 于 2010-03-01 1:44 上午

    to MT,其实我不是有喜欢X的癖好,我是想通过这样的讨论多学习东西啊,我又不是来给谁做广告的。我就是想听听各位大牛说说他们的想法,以后我去跟别人聊天的时候也可以把学来的东西举为己用,装把“博学”啊
    我多少有点被虐倾向,就是喜欢有牛人给我指点迷津,让我多学点,说不定哪天有人说X好的时候,我说不定又站在对立面了呢。只要大家说的有道理就行啊:)
    何必为了喜欢和不喜欢做那种无畏的争论呢

  89. Multithreaded 于 2010-03-01 1:55 上午

    抛块砖,引玉把。

    1。 NPU市场长不大。两年前大概是$100M多一点. Intel占了半壁江山,谢谢H&Z:-)

    2. Intel已经退出了这市场,这块小蛋糕够不够Cavium,RMI,LSI, X, E等分哪?有人会活下来,但我不推荐你买他们的股票。

    3. 10G以下的NPU设计没有什么难点,中国的H和Z应该有能力搞定。难点是HW and SW co-design, especially HW design impacts on SW programming and performance.

    4。40G/100G的NPU想收到钱还远着那。

    5。Intel/AMD/IBM的多核会把NPU的设计吸进来。不过小强同学可能等不及了。但是要想到你今天写的程序明天如何移植到多核来。

  90. 小强 于 2010-03-01 2:13 上午

    to MT: 这个帖子看起来还是有一定功力的:)
    目前业界有能力做出40G/100G NPU的(做得好的),目前只有X和E吧,所以如果以后还是$100M的话,那么我强烈建议买这两个公司的股票,因为这两个公司真的很小,$100M每年的话够把他们养的肥头大耳了。当然现在是多大的利润了我也不是很清楚了,可能没有这么大了,需要调查下。
    对于20G的NPU的话,现在市场足以让X和E活到他们的40G和100G赢得利润的时候。您说的远着呢有多远呢?我相信最多两年之内一定会有收益的。
    10G以下的NPU目前我觉得H和Z不一定搞吧?他们的胃口应该不仅与此,所以对于X和E的未来的确有点担心,那就是当H和Z有了高性能NPU怎么办?但是那需要相当的时间,至少Z可能需要很久
    您说到的这些,其实NPU的厂商早就看到了,他们已经在酝酿着更多的东西了。
    NPU长不大是指多大呢?其实长多大不重要,重要的时候能不能养活做它的人。我觉得NPU有着他长期存在的理由。
    隐约感觉你很推崇多核啊(可能感觉错了,不过觉得您好像和intel的渊源很深啊…),多核提出有一段日子了吧,怪不得您不喜欢流水线架构,这本来就是两个相对对立的概念,我倒没有不喜欢多核,我喜欢强者,但是目前我更喜欢流水线:)偶已经不编代码很多年了,如何移植到多核不是我考虑的了,但是移植那一天的到来说不定要很久哦

    不过说句实话,您的这个命题对我来讲有点不那么手拿把掐了,反正我是不知道哪天NPU会死,也许明天,也许很久都不会

  91. Multithreaded 于 2010-03-01 2:23 上午

    我想问的是

    1。 5-tuble的classification是否放到TCAM里做了?

    2。 longest prefix matching要花几个PB要多少指令?

    一般来说IXP2800的一个engine可以有8000条指令,它对应的是X的一条Pipeline, 完成所说的复杂业务. 640即使成以4已比8000少很多。

    大概X把有些“难”的操作交给co-processor去做了。

  92. Panabit 于 2010-03-01 2:28 上午

    据我所知,IBM两年前就在研发多核网络处理器(现在应该出来了吧),吸收了很多NPU方面的内容进去。NPU应该还会存在一段时间,不会轻易退出。

  93. haha 于 2010-03-01 4:47 上午

    这里真热闹,x和e是2只癞蛤蟆,x后腿长一点,e是前腿长一点。x说我的后腿长,最漂亮;e说我的前腿长,也很英俊。他们都没有看见过青蛙。

  94. haha 于 2010-03-01 4:56 上午

    本来以为能学习到东西的,就看见口水仗

  95. 陈怀临 于 2010-03-01 6:40 上午

    不会吧?我还想把这篇文章的评论单独整理成一篇文章呢。例如:关于NP的讨论–X和E的聊天。

  96. 小强 于 2010-03-01 7:19 上午

    to all,既然牛人们都纷纷站出来总结发言了,咱也就不多说啥了,只是偶也想学习,至少我还从大家的讨论中多少学到了些东西,只是haha同学的总结实在是太好了,好的让我这种没学问的人看了有点无地自容了,那我们就静待有学问的人出来写点东西让我们这种无知的人多学习点东西了,也很期待haha多教大家点哈。
    只是到时候haha别也就是吐口水的本事就好。

  97. 陶潜 于 2010-03-01 8:13 上午

    这段时间在旧金山附近出差,
    一直想见见首席,当面讨教。
    hi 首席:
    不知道方便否?

  98. 陈怀临 于 2010-03-01 8:47 上午

    我目前肉身在辽国旧金山机场,前往大宋幽卅城…7曰回来…给我E吧。。。

  99. 陈怀临 于 2010-03-01 10:46 上午

    在SFO机场,一批大宋子民访问团。。。在候机大厅扬我华夏神威,大吵旧金山,与自己的导游就差动手….真开心呀,机场上下的番人看得以为是show.
    大宋子民真让首席自豪自己的祖国呀!
    如果今天UA889因为有人在洗手间抽烟而出事,我一点不奇怪。。。

  100. Multithreaded 于 2010-03-01 11:59 上午

    我大年初一飞UA888, 原以为能躺着回来,结果是满舱,前后左右都是孩子。

    国人真有钱,可以全家到美国来玩,不知这签证是如何办下来的。

  101. Multithreaded 于 2010-03-01 12:25 下午

    聊点专业的把。

    据说H&Z在攻40G的NPU, 我个人的感觉是

    1。 先把10G拿下,锻炼锻炼队伍。 然后上可供40G,下可把X&E etc. 在接入层扫地出门。

    2。 40G/100G的东西,用一下X&E的产品,搞个Demo.什么的能向科技部交差就行。 现在企业的数据中心和TOP 500 Super Computers主要的还是10G的天下,还要有3-5年的时间才会大量用到40G/100G.

    3。 为什么不做10G的NIC? $1,000多美金一片,比10G的NPU还贵,量也大得多。 要学C进入Server市场,NIC这一关是否得过?

  102. Multithreaded 于 2010-03-01 1:28 下午

    〉〉隐约感觉你很推崇多核啊(可能感觉错了,不过觉得您好像和intel的渊源很深啊…),多核提出有一段日子了吧,怪不得您不喜欢流水线架构,这本来就是两个相对对立的概念,我倒没有不喜欢多核,我喜欢强者,但是目前我更喜欢流水线:)

    其实我非常喜欢流水线架构, 现在考虑的问题就是多核架构下的流水线并行模型。比如10G的TCP/HTTP协议如何用流水线实现? 请注意我的一个pipeline stage可不是32条微码。

    我不欣赏的是把硬件流水线的微码编程方式强加给软件人员。 Verilog/VHDL适用的流水线编程模型可以在L2/L3上用用,但不应该当成是唯一的或者最佳的选择。它对软件维护的杀伤力是蛮大的。想想看,C的QuantumFlow NPU为什么不用类X的流水线架构?

    其实我们俩的分岐是在对流水线的grainularity的掌握上。让我们求同存异,今后不要乱扣外行的帽子就行了。 因为这世界上本身就没有外行,每个人可能只比其他人早接触了一点而已。

  103. kkk 于 2010-03-01 8:42 下午

    说到counter,不知道关注的人多不,的确遇到过某芯片的counter不太精确,千兆的环境,很快的速率读寄存器的counter然后累加的值就不对(寄存器是读清的),1w个包就会老差一两个,但是一次读就没问题,呵呵

  104. kkk 于 2010-03-01 8:43 下午

    最后他们的工程师确认是芯片的bug

  105. haha 于 2010-03-02 8:14 下午

    to kkk, 某芯片是x?我从Hw了解到曾经发生过这样的事情。
    to 小强,我费尽9牛之力,想从网上搞到一点点x或e的资料,实在很少,都不够唾沫星子。

  106. 楼上楼下,电灯电话 于 2010-03-02 8:33 下午

    很有意思的讨论,存在就是合理的,无论X或E。这年代剩者为王,看谁能笑道最后。

  107. 数通人 于 2010-03-03 2:26 上午

    要灵活就CPU,要快速就ASIC,这是亘古不变的原则。各家的NPU不过是走在CPU和ASIC之间的灰色道路上,无非有的偏硬,有的偏软而已。都有自己生存的空间,无非有的大点,有的小点而已。今天在finance.google翻了翻通讯芯片公司和国内网游公司的业绩,老大BCM有44亿美刀的营收,却只有区区6千多万的净利。完美世界4.5亿的营收,净利则高达2亿3千万美刀。所以能理解钱老大为啥要改logo,为啥要收flipvideo了,还是老百姓的钱好骗啊。

  108. 理客 于 2010-03-04 6:22 上午

    对于NPU,不要说全业务,就是基本的IP/MPLS L2/3业务,二层交换,QinQ,MPLS TE, VLL/PW/VPLS/VRF,组播,TRIPLE PLAY,QOS, ACL等等,还不算BRAS/IPV6/NAT等,要是没有ASIC做上面的基本业务,两个X11都很难应付,还不要说X11致命的一旦不能线速,就会性能大幅下跌到基本不能商用,而不是像传统模式的CPU/多核/NP一样,性能下降是一个比较平缓的曲线。要说用X11作为主转发引擎的协处理器,那是非常好的,但要是颠倒过来作为主力,那有点主次倒置,颠倒了。目前的商用系统基本主要是NP+ASIC模式,而不是纯NP的模式,已经说明的了纯NP在功能+性能的满足度上是有不能解决的问题的,哪个大供应商没有一些大牛,所以他们很清楚这些关键问题,不是很容易被别人忽悠
    当然,实际的系统架构的设计还要考虑成本、X小公司的稳定性和前向兼容等问题,就更复杂了,所以目前的高端系统,门槛是非常高,整个系统包括CPU、多核、TCAM、查表器、NPU、ASIC、FPGA等多个核心硬件部件,把他们统一运行成一个商用系统,目前只有有数的几家大供应商可以负担得起,这不是一个纯技术问题

  109. Multithreaded 于 2010-03-04 7:37 上午

    同意#108地分析。

    NPU在10年之内没有成长当初预估10亿美金的一个市场,是由它深刻原因的。估计永远长不大了。

    但1G以下的市场不用NPU, 有点说不过去。 在接入层,假定功耗和价格不是问题(将来不会是问题),为什么一片NPU或多核搞不定你说的业务哪?

  110. mpc8240 于 2010-03-05 2:12 下午

    国内的筒子推崇NPU的原因其实很简单,没机会体验过C/J/A的ASIC。ASIC做好了programability也是很强大滴。H牛气是牛气,动辄换NPU chip vendor,没有多年的继承,和C/J/A竞争也就只有靠性价比了。

  111. 陈怀临 于 2010-03-05 3:58 下午

    同学,这里H,Z等等的弟兄们很多滴。。。你被他们的口水淹死,可别怪首席在旁边乐。

    我这几天在幽州太忙。明天回去。我把这次NPU,ASIC等的大讨论整理成文。。。

    我会从一个设计过一个网络处理器编译器的工程师的角度来讲一哈。

    有设计和整个走过一趟编译器backend的人吗?:–)。咔咔咔咔,大家都安静了,估计。。。

  112. Multithreaded 于 2010-03-05 5:58 下午

    听说过Intel IXP -A 和 -C 两个C自动编译器吗 :-)

  113. Multithreaded 于 2010-03-05 6:05 下午

    #100, 国内的筒子推崇NPU的原因其实很简单,没机会体验过C/J/A的ASIC。ASIC做好了programability也是很强大滴。

    第一句好像有点道理,第二句不太准确。

    ASIC can be configurable but not programmable.

  114. 楼上楼下,电灯电话 于 2010-03-05 6:15 下午

    #108 很精辟

  115. 老刘 于 2010-03-05 6:27 下午

    如果是GCC的backend,简单的说。没有你想象的那样复杂。

  116. 老刘 于 2010-03-05 6:36 下午

    什么ASIC不ASIC,思科的QFP ASIC实际上不就是一个NP。

  117. 陈怀临 于 2010-03-05 6:47 下午

    小刘,你还真牛了。你要是加过一个target,我还真不信了。什么叫做GCC的backend。我的意思是加一个ISA的target。你在想什么呢?如果你不是计算所的,或者原来Intel的那票人(MT你先不要乱讲:-)),我还真不信你懂我在说什么。。。你不要来个什么简单的说。你可以复杂的说一哈。。。

    没想到,还有人觉得自己编译牛的。真是来劲。

  118. 老刘 于 2010-03-05 7:01 下午

    小弟不才,我也不牛。我就是说没有你说得那样的玄。

  119. 陈怀临 于 2010-03-05 7:59 下午

    你非要拿什么图灵奖的理论工作来比较,这就没法说了。。。

    编译器难在对一个target的微结构的利用和优化上。例如,对性能的损失的控制。另外,对网络处理器的编译器,对特殊指令的设计和处理是最难的。。。。。。MT是个牛牛。我们让他多说说。。。

  120. 老刘 于 2010-03-05 8:09 下午

    都这么说了,我也就不是说了。

    是牛人的站出来。你们讲,我来听。

  121. 杰克 于 2010-03-05 10:38 下午

    面过intel 做ixp编译器的人,后端的优化做了N多遍,经历最重要,讲里面有多高多难的技术,谈不上。在里面钻的多了,体会自然就来了。哪一行都是这样。

  122. 理客 于 2010-03-05 11:07 下午

    Multithreaded:我很同意你的idea,严格说,我属于外行,一块NPU的代码限制,我拿不出强强喜欢的具体数据,但是从到目前为止的实践上确实是搞不定,因为代码空间就是XXXK,除非通过license控制,但这种为了解决代码空间而做的license,在实际使用过程中涉及到如何做group features 、测试工作量增加、maintenance…等很多问题,说起来简单,做起来是比较trouble的。至于多核,是不存在代码空间问题的,除非把需要处理的业务代码全放到cache中,那就有和NP类似的问题,目前,好像还没有这样用多核的,有这样用过的大牛可以站出来show一下,IP从初始的单纯的IPV4转发到现在的支持所有电信和非电信业务,即使是基本功能,也扩展了N倍,用C码实现所有这些功能,编译一下,应该也上M了吧,微码再优化,也还是需要很大的代码空间。总结来说,原因就是:
    1、NP代码空间受限,CPU/多核不受限
    2、目前路由器的主要业务对代码空间的需求已经很大
    一些可以考虑的方案是把ASIC完成的IP的已经成熟固化的主要功能集成到NP中,作为一个特殊的指令调用,当然这时候成了一个CHIP里,谁主谁付,外外面看来就可以不那么强烈的去争论了,不知道是否有这样的feasibility或者有人在实践,目前的商用都是NP+ASIC的分立模式,并且分立和融合,在scalability、consumption、flexibility、feasibility等方面比较起来也是各有利弊的,不好一概而论。
    如果不不从技术细节,从市场效果来看,好像只有J在宣传或者实践programmable ASIC,J的产品在技术上不得不说应该是不错了,那么可以从侧面证明其programmable ASIC应该是做的不错的,当然,个人认为比其他的C/H/A等都强很多,毕竟J在这方面浸淫和投入了N年,这是他们的know how。当然我还是没有强强同学喜欢的数据,希望有大牛出来扔东西。个人粗浅的理解,J是把IP处理分解成合适的原子操作,这些操作又可以根据一定的规则做组合,但能否做具体变量的加减和条件处理,不知道J怎么做的,也许只是advertisement, not real。有一两个同学说在这里只看到争论,没看到有意义的技术(大意),这是超级的不符合事实,这个帖子,是除了很久以前关于多核CPU帖子外,少数几个涉及到很强的关于NP的前沿的技术实践的帖子,强强贡献最大,按这几天不露面,让喜欢强强的FANS,比如首席,有点寂寞:)

  123. 小强 于 2010-03-06 7:21 上午

    好久没上来了:)
    看到牛人们的讨论,觉得学到了好多啊
    说下X:)
    X11已经是上一代的事情了,X11针对的市场主要是城域以太网,包括PTN和以太网交换机。在实现这方面的功能时候一片X11足以线速,有市场成功案例做支撑,我想不用多说什么了
    针对路由器市场,X11的确无法一个人完成全业务,要么两片,要么X11+ASIC,后者在市场已经有成功案例了
    X的下一代产品近期就会面世。现在很多产品都在评估这款芯片,由于还没有拿到Demo所以现在都是纯理论分析,对于城域以太网,PTN,企业网,OTN以及接入市场来讲,一片达到全业务线速不在话下。现在的重点在路由器,路由器产品目前我知道的某知名大企业的主打产品评估下来是一片HX可以完成他们的全业务。路由器的确有非常变态的业务,在这种非常变态的业务出现的时候运营商不要求线速。而我在前面的很多个回复中都谈到了HX新增加了一个功能就是支持部分业务不线速,而不是X11所有业务要么权线速,要么全部线速的机制。这个机制的引入已经完全可以满足路由器的需求了。
    当然如果要所有变态业务都线速的话,需要2片HX。
    至于何为趋势,我的确知识浅薄,虚心向各位学习请教,不过据我所知C也在选择商用NPU芯片,而J也是在做自己的NPU,并不像大家认为的放弃NPU只做ASIC方案哦

  124. 理客 于 2010-03-06 7:46 上午

    个人粗浅的胡言预测:HX再HHX也还是要+ASIC,除非它把之前ASIC完成的IP/MPLS基本业务seamless集成到其NPU中。NPU的重要性毋庸置疑并且无可替代,但NPU的在代码空间+性能的双赢是做不到的也是天然缺陷。在运营商L2/2.5/L3/MPLS/TE/VLL/PW/VRF/TDM/ATM/FRR/BFD/OAM…等等,你要敢说是变态业务,operator得把你P了,实事求是的说,运营商确实有变态的功能,但大部分是没有变态的,像上面的业务,都已经基本成了基本需求,这些业务的实现,我不看好HX在没有ASIC的情况下能摆平,即使摆平了,我们系统设计难道不留出20%的余地?如果你不做一定的预留,operator还是要P你:)都知道银行里银子多,可不好拿呀:)所以胡说的预测是:评估后的结果还是NP+ASIC,希望到时候能有结果出来show一下看看到底鹿死谁手,花落谁家?

  125. 理客 于 2010-03-06 8:13 上午

    看到强强的评估结果,如果是40G的降速到20G甚至10G来支持运营商要求的业务,这是可能的。但是这又和目前运营商已经要求100G/slot不符,所以还是不能单HX甚至双HX用在主流的线卡上,所以认为商用的主流产品还是HX+ASIC,但不排除部分低端产品,比如不要求100G/SLOT的产品用纯HX的方案

  126. Multithreaded 于 2010-03-06 9:17 上午

    #118说的可能是GCC的移植工作,这玩意是难者不会,会者不难。难在搞稳定了。

    #119说的是另一个高层次问题,修改GCC后端的关键算法,提高代码的生成质量。比如: Instruction scheduling. Let’s assume a non-blocking thread execution engine, given two memory reads, one is read from SRAM and the other is from DRAM, which one shuld be issued first? If two reads are both SRAM reads, which one should be issued first?

    这里的难点是:
    1。诸如此类的优化一般来说是NP-hard问题,解决好一个就可以PHD毕业了:-) Frances E. Allen由于她对Fortran Compiler的贡献,拿了2006年的图林奖。

    2。你写的优化是GCC上百种优化的一个,如何做到对其它优化没有破坏性的影响。比如,优化完了, 如何让.debug section 正确, make GDB work.

    最难的是当硬件的人要加一条新的指令时,你得考虑到对程序员(language extension),编译器(GCC tool chain),和系统性能(performance evaluation)的影响,决定加还是不加?

    Of course, no company could have done the above correctly yet. These are simply personal experiences, please take it as a grain of salts.

  127. Multithreaded 于 2010-03-06 10:41 上午

    杰克说的对,实践出真知。 任何一个NP-hard问题,只要找到了启发式算法,也没什么可怕的。多做几个,也就家常便饭了。

    不过第一个吃螃蟹的人,是要有勇气和智力的。

    我就挺佩服#120的勇气的,敢于在COMPILER上挑战陈首席。

    不过COMPILER何NETWORKING的研究方法好像不特一样。 Compiler optimizations more focus on algorithm design and network design more on entire system performance. 编译的人喜欢精雕细琢,网络的人要有大局观,喜欢一览众山小的感觉。

  128. singlezhao 于 2010-03-06 10:24 下午

    40G据说好象已经拿下了吧

  129. 跳跳虎 于 2010-03-07 7:40 上午

    ASIC比较容易做到线速;NP可以比较灵活,根据不同的应用,互相配合应该是一个趋势。
    做到高速焦点就是存储带宽的问题。TCAM,RLD等都太贵了,ddr首选。低速FC肯定首选DDR。

    看到各位牛牛的发言,受益匪浅。期待陈首席的整理。

  130. 楼上楼下,电灯电话 于 2010-03-07 6:18 下午

    同意理客观点 HX + ASIC

  131. 小强 于 2010-03-07 6:35 下午

    to 124&125之理客:你说的那个业务当然不是变态业务,但我就是始终纳闷的你怎么知道NPU放不下这些业务,交流几次下来发现您没有一次从技术分析的,都是一些表面的定性般的分析,的确有点不想争论了。你的业务还少,还应该加上APS保护,LAG负载分担,LAG1:1,QOS,ACL,L2VPN(VSI)和L3VPN(VRF),生成树,IGMPv3,L2 security,甚至还有曾经很热的PBT,PBB等。这些别说HX了兄弟,X11单片就拿下了,HX对这些预留30%都绰绰有余。
    还有,您用过NPU没有?现在主流的数据核心的NPU怎么可能处理ATM和TDM?我就纳闷您怎么把他们也加进来了?现在如果要支持ATM和TDM的话,都需要接接口卡,接口卡上把TDM/ATM/POS等业务接受下来,转换成数据报文转给NPU做数据转发。
    我本来想渐渐退出这个系列的评论,给我个机会,不要总诱惑我说话,呵呵
    对于HX来讲,单片能否完成最变态的路由转发,也就是所谓的3层上的什么uRPF啊,uRPF再uRPF啊,IP下隧道再uRPF再上隧道啥的,这种操作实在让人崩溃,这种东西,一片HX是不行的。其实我上次说2片HX,其实说完的时候我发现我说错了,因为这不是某大型公司的评估结果,他们的评估结果是HX+AX就可以,两片HX要比HX+AX强大的多,但是HX+AX就够了,您的两个HX也一样不行,到底是什么依据啊?实在无法理解您的结论是怎么来的?
    对于最后鹿死谁手,这个的确不好说,就算以后结果是HX+ASIC,那也不是因为两个HX不够用,而是出于成本啊,政治因素,市场因素等等的结果,而不是您所说的够用还是不够用,而加的ASIC也不会是商用ASIC,而一定是某公司自己的ASIC。

  132. 小强 于 2010-03-07 6:43 下午

    再to125 理客:我发现您对X的片子成见很深啊,至少您对我的帖子基本是只看一部分,只看哪部分您能反驳,而不是看我在说什么。我一再说现在HX已经不是要么40G,要么20G,要么10G的成倍下降了,我说多少次了?他可以区分业务的下降性能?我咋发现我说了就跟白说一样,你一样不停的在那固执的回复呢?
    还有,您的这一切都是建立在NPU的代码,性能是问题的前提下,而这些我前面说了无数次了,就您提的那些需求,真的简直就是小菜一碟,您是不是非常怀疑NPU为啥能做到啊?那您问问做NPU芯片的人吧,我想您能得到您想要的答案。
    ASIC+NPu会有这样的方案的,我们现在就能看到,但是单片NPU的高性能卡现在也是非常多,您去看看行不。我再说一遍ASIC+NPU的方案不是因为NPU做不到,而是成本。我从来没听说X11+BRCM的ASIC做方案的,作业时X11+某公司自己的芯片,这是为什么?您想想就知道了,明显是成本。真是不明白您的结论都是咋得出来的

  133. manjusri 于 2010-03-07 11:25 下午

    小强同学,多谢回复。个人确实没有NP的细节知识和经验,这里ASIC一般指vendor自己做的ASIC,而不是商业的,成本和politics也是必须考虑的问题。HX还在没有正式商用,所以以个人有限的经验,HX前还没有人在成功的在carrier的PE位置的SR上推出纯NP转发的产品。即使HX,个人也认为无法达到性能+功能双赢,更不用说再加上成本和功耗了。当然,毕竟HX还没有真正商用,不能说HX就真做不到,非常希望HX能做到,这是很多人的福音,如果真的是这样,那么HX创造了NP的新历史,个人不相信HX能做到,具体什么specification呢:单片NP,50G双工/100G单工,支持carrier的PE位置的SR的非变态业务,预留20%上代码空间,可以允许部分不常用的功能80%线速。功耗和COST等基本问题就不必说了,我非常肯定的认为HX做不到,当然HHX也许可以,所以个人猜测这个PE的SR,最终的商用方案还是HX+ASIC,当然,这个结果,我们也许今年年末或者晚一点明年年初会看到。
    目前商用的PE的SR,纯NP的线卡,并没有成功的被广泛应用,即使用的比较多的,也像小强说的,里面有vendor的强大历史和政治地位,以及特别的场景在里面。相反纯ASIC的线卡,要比纯NP的线卡用的广泛的多,当然,同样也有上面的非纯技术因素。
    至于ATM/TDM,小强解释很正确,大部分工作为接口卡完成,但是转发引擎也要所一些事情,尤其是ATM的PVC/QINQ/QOS处理,所以ATM是个看着是个完美的美女,可用起来总让人不那么爽的感觉。事实上,个人并不指望HX能把这种也可以认为有点变态的需求放进去,目前的商业产品在综合考虑后,一般是用另外单独的新卡处理
    以上发言,如果努力搜寻,可以找到部分数据支持,很抱歉没去做。
    对于HX似乎强大到做那么多事都小菜一碟的地步,我还是真的不相信有那么神,感觉是过分的市场宣传,所以才这么怀疑。如果小强或者这里的大牛能show一下HX到底为什么能如此强大的一些key points,相信这里的同学都很喜欢听到和学习
    再次感谢小强的强力回复,非常欣赏,希望小强能继续关注这个热点问题,谢谢!

  134. manjusri 于 2010-03-08 12:32 上午

    忘了ALU的IOM3,还是IOM4?应该是NP吧?是自用的,不清楚其代码空间等内部细节

  135. 小强 于 2010-03-08 1:59 上午

    to 133和134,改名了?
    不过不管怎样,我真的是不想再说这个东西了,您说的那些特性,一片X11就OK,现在有成功案例啊,当然不是您说的路由器,可是不是路由器不是按照这几个业务来评判的,就您说的这些业务PTN产品全支持。您去查查一片X11能不能把这些全做了,而且加上我说的那些功能,一片就是可以全做进去,为啥您就一个劲的在这说不能啊。我无论如何找不到让我继续争论的理由了。HX比X11支持的更多,这毋庸置疑。您想知道啥?我可以讲给你,但这的确不是我应该做的,您可以去找点资料自己看,或者找几个你的人脉去了解下。
    兄弟,我说了最后是纯NP还是ASIC+NP的方案,不一定取决于NP能不能做,我展开说下吧,否则我想争论会不休的。大家都知道一块单板的成本除了核心芯片外,还有外围BOM,这些是很重要,所以真正选择方案的时候要比较的是NP+BOMa和NP+ASIC+BOMb的成本,如果一个ASIC可以节省NPU很多BOM,NP不需要满负荷跑起来,很多外挂不需要的话,也就是说BOMa的成本大于ASIC+BOMb的成本,那么很可能ASIC+NPU的整个成本会下降,用ASIC+NPU当然合乎情理。而这并不是说NPU一片搞不定。所以,我从来没有说ASIC+NPU的方案不可行,而且很可能是最后选择的方案之一,可这能说明什么呢?恰恰说明NPU还是有存在的价值的,NPU还是必须要用的。
    而且,兄弟,我已经说了,现在某大型公司的边缘路由器的评估结果了,难道我们不信一个强大团队的评估结果,而信您的拍脑袋结论?不过事情就是这样,说不定您还最后就说对了,但那纯属巧合吧

    请您别老盯着所谓路由器,眼界宽点,看看交换机和PTN,甚至接入,PON和OTN,说明一点,别以为接入,PON和OTN就是低线速的代名词,他们的速率一点都不低,现在都是在走40G和100G路线了。他们的业务是您说的那些业务的超集,这些人早就用NPU方案实现了。您去看看现在全国乃至全球最NB的PTN产品是怎么做的,回来咱们再讨论

    我说了,路由器相对的变态业务的确不好做,但是您说的真不算啥,您说的根本就是路由器业务中最基本的,你咋还不明白呢?你看看尼采说了几个业务,就那几个业务要是NPU做不了,那就别混了。

    我很乐意讨论技术细节,但是我的确发现您没有拿出讨论技术的诚意和足以让我用更多的数据来证明给你看的资本,我为什么要讲很多?除非您的确说出了让我觉得值得用数据反驳的东西,否则真想拒绝讨论下去了

  136. 阿土仔 于 2010-03-08 6:48 上午

    小强是X公司的人吗?

  137. 理客 于 2010-03-08 6:55 上午

    最大的分歧点在于:
    1、严格讲,PTN可以算作路由器,但远不能算在运营商PE位置的SR路由器,并且在CSG位置的mini BOX前途比较好之外,其他的前途就不好说了,HX可能会带来改变,但整个系统可能不再是原来PTN的架构了
    2、目前在IP转发设备中,没有任何位置比运营商PE位置的SR路由器功能+性能要求更高
    3、小的更边缘的路由器也好,PON/MSAN等也好,X11应该没有大问题,尤其是HX,但是绝不是运营商PE位置的SR路由器,这里成本和politics是一个考虑,X不能胜任100G下的性能+功能也是一个重要原因
    4、因为城域网中的SR路由器是最复杂最重要的地方,所以我只关注它,其他位置,X和NP是可以做的,所以我不关注
    5、如果去做运营商PE位置的SR路由器方面SE,您会对业务的理解更深刻,可能会有不同的体会
    6、我不认为您说的团体的评估结果会让运营商PE位置的SR路由器的架构变成纯NP结构,相反,我认为这个位置,他们最后还是选择HX+ASIC,并且HX不能100G下的性能+功能+代码空间预留会是一个重要原因,如果他们强用双HX方案,个人认为将来很可能是一个不太成功的产品。我唯一不解的是ALU的IOM3.4?作为NP架构的SR是如何做到的?上面评论有武断的成分,HX做到了IOM3/4?单片100G+SR功能的水平,当然不能说没有可能,如果能做到,那业界的大好事,我是基于经验大大的怀疑,如果我的怀疑错了,我一样是非常非常happy
    7、澄清一下:
    (1)NP的重要性无可否认,必须要用
    (2)PON和OTN是当然是高速,不是低速
    (3)PON/OTN/SWITCH/PTN等等位置的功能,除了物理协议上特别的需求外,其他IP功能大体上是城域网的SR的一个小子集,绝不是反过来
    很喜欢您的细节,很惭愧个人技术能力达不到细节的水平,anyway,希望能再次欣赏和学习到您的评论

  138. 小强 于 2010-03-08 6:50 下午

    to 136,你为什么不说我是H公司,或者是某其他公司的呢?

  139. 小强 于 2010-03-08 6:59 下午

    to 137,喜欢你这个帖子,说的要比前面的有内容多了:)
    其实我也不太关注细节很久了。我就吹牛很厉害,惭愧
    城域网的SR当然是个更大的集,这点我承认,所以我觉得在很多变态的业务情况下,一片NPU很难线速。两片是一个选择,而且目前看能做出来是肯定的,唯一不肯定的是成本。但是像H这样有自己ASIC的大公司不多,所以不是所有人都能用ASIC+NP,所以有的公司无论如何都要2×NP,就像以前的EZ的NP2和NP3,有的单板上面居然有6片之多,为什么?没有相关的ASIC来一起用啊,买商用的ASIC还不如多用几片NP呢。所以我觉得有能力有自己的ASIC的,选择ASIC+NP是一个好处,尤其是BOM成本的因素。没有ASIC的,用多片NP也觉得可以,功能性能不是问题,大不了多放一片
    偶虽然一直做SE,但的确没做过边缘SR的SE,惭愧,愿意多向牛人学习

  140. 数通人 于 2010-03-08 7:12 下午

    new CRS is coming, don’t look down on QFP.

  141. 理客 于 2010-03-08 9:33 下午

    没有自家ASIC的并且也没有计划自己做ASIC的,用两片HX确实是最好的选择,并且如果HX足够好,那么会被非常广泛的应用在IP设备中,希望HX的市场拓展和售后交付能够和产品推出与时俱进

  142. 老刘 于 2010-03-09 3:01 上午

    数通兄,
    您的意思是新的CRS用了QFP?

  143. 小强 于 2010-03-09 3:09 上午

    弱弱的问一句QFP是啥啊?

  144. 老刘 于 2010-03-09 3:27 上午

    强强,

    赞你一下,你是相当的内行。

    QFP是思科自己的ASIC,看看这个
    http://www.tektalk.org/2010/03/02/%E6%80%9D%E7%A7%91quantumflow%E5%A4%84%E7%90%86%E5%99%A8%E4%BD%93%E7%B3%BB%E5%88%86%E6%9E%90/

  145. 数通人 于 2010-03-09 5:24 上午

    New CRS platform, 322T.

  146. 老刘 于 2010-03-09 6:15 上午

    CRS-3 multi-chassis 322 Tbps牛。

    这个QFP跟ASR1000的QFP有何区别?

  147. 阿土仔 于 2010-03-09 6:21 上午

    有个问请教一下小强:就是X11没有硬件parser,那做parser需要多少条指令完成呢?感觉x11的指令确实不多,而且parser是不是第2个EAP前就要做完呢?

    注:我没有编过NP的代码,我是做RTL的,从我编RTL的角度考虑我觉得报文解析还是需要很多指令的。如果问的比较业余,请见谅,最好能有个x11的parser的代码示例,谢谢!

  148. 陈怀临 于 2010-03-09 8:34 上午

    小强,你别吓我们,好不好?你忽悠了我们半天NPU,ASIC。我们每天加班查资料读您的points。突然你问我们QFP是什么。你这,这,这。。。

  149. 老刘 于 2010-03-09 3:25 下午

    那是逗你玩。。。
    强强还是很赞的。

  150. 老刘 于 2010-03-09 4:24 下午

    CSR-3的QFP由六个芯片组成。

  151. 数通人 于 2010-03-09 7:41 下午

    准确说是设计了六颗新芯片,整个系统要12片组成。

  152. 小强 于 2010-03-10 12:57 上午

    to all,终于发现出来混是要还的,呵呵,我的确不知道这个东西,我会跟上大家的思路好好学习天天向上的。别冷嘲热讽我了,不知道就是不知道,以前不知道不一定以后不知道,请各位大牛多指教了:)

  153. 小强 于 2010-03-10 1:02 上午

    to 147:parse无外乎对报文的某些字段进行比较,判断,以此判断报文的类型等等。据我所知EZ在这方面做的很好。但是我也知道X11在这方面也做的不错。我设计过的产品就用过,如X11可以通过内置TCAM来完成,在第一个EAP点就可以完成,报文一进来就通过内置的TCAM将报文识别出来。

  154. 小小牛皮U 于 2010-03-10 1:10 上午

    CRS-3用了QFP?是不是下一代的新芯片啊?

  155. 小小牛皮U 于 2010-03-10 1:14 上午

    ASR9000也正式发布了吧。ASR9000采用了8片NP3c,120G吞吐量full subscribed,160G吞吐量over subscribed。上Cisco的网上看了一下,线卡上最多出8个10GE口。这样算NP3c最多也就7.5G duplex的处理能力,而且是只供货给C。
    按照NP3c处理能力1.5倍NP3算,NP3只有5G duplex处理能力。NP3c频率和NP4一样都是400MHz,真不知道NP4怎么做到40G duplex/100G simplex处理线速的?也许NP4会让选用的制造商门大失所望一把了……

  156. kman 于 2010-04-16 7:40 上午

    我支持小强,不过我没用过e的。x的NP,架构很好。你可以知道实现的业务能不能达到线速。不过串行的业务扩展起来不方面。对深度解析和封装的需求会有点麻烦。

  157. kman 于 2010-04-16 3:36 下午

    请教一下np+asic,asic可以做什么业务呢?小强是估计是某某公司的,去年应该就在设计了吧。现在方案是应该出来了,呵呵

  158. Spark 于 2010-05-26 3:17 上午

    小弟刚刚出道啃NP4,最近还要拿个key unlimited的方案,看到各位大虾的精彩评论,收益非浅,非常期待首席的整理文章

  159. wyzzh 于 2010-07-13 2:50 上午

    X的东西感觉就是一旦定型后面如果改动会很麻烦。另外做到线速转发所有的业务有这样的路由器吗?哪家测试性能的时候不都是跑个2544就好了,至于怎么解决单路由的冲突就看NP有没有内部的SRAM了。X不知道是不是跟HW签过了一个什么条约,反而把自己害得快倒了,等8月份的sample到了看看怎么样吧。路由器的变态关键是看能不能通过几家运营商的测试,至于业务用两个NP哪有什么实现不了的。

  160. bagua 于 2010-07-14 9:47 下午

    159楼 X不知道是不是跟HW签过了一个什么条约

    这是啥东西啊?

  161. Tony 于 2010-08-13 7:34 下午

    楼上各位的点评实在是精彩, tektalk真是卧虎藏龙。作为一个未入门的新手,往谁能否帮着介绍一下 FPGA,ASIC, NP 和SoC之间的区别和联系?从具体应用level和以及Coponement组成上,刚开始介入这方便的学习上的说。

    谢了先

  162. coder 于 2010-08-14 1:35 上午

    @Tony

    Google could help you :)

  163. Tony 于 2010-08-14 11:01 上午

    由于实在是没什么design的经验,googld的东西非常抽象, 个人感觉现在ASIC做的越来越强大, 包括二层三层交换,ACL,HQoS都可以用一块集成的Chip来实现, 现在Broadcom, Marvel的芯片是否属于ASIC的范畴, 而EZChip, Xelerated做NP,其实10G,20G现在ASIC都可以实现,而且性能会更好, 为什么我们还要NP呢?

    而FPGA,差不多一块FPGA芯片也可以实现一些复杂的功能, 比如1588 PTP clock, Ethernet OAM, IP SLA等功能,

    所以望各位前辈解释一下困惑,在实现一些具体的功能,FPGA, ASIC, NP 如何选择?

    谢谢。

  164. Re 于 2010-08-14 3:01 下午

    FPGA可以重复配置,但功耗和成本高,集成度低。
    ASIC相对FPGA,成本和功耗低,集成度高,开发周期长,不够灵活。
    NP是内潜了CPU的ASIC,灵活性好,但转发性能上相对纯ASIC要弱一些。

  165. 陈怀临 于 2010-08-14 6:17 下午

    现在流行山寨。拿货架上的东西组装。off-the-shelf…没事别自研silicon.除非大公司。

  166. rrr 于 2010-08-19 7:06 上午

    用FPGA来完成NP实现的功能,你可以想象需要什么杨的团队才能完成?如果用FPGA做出来NP了,能忍得住不去流片吗?

  167. Veteran 于 2010-08-25 12:30 上午

    有人了解 Cavium Networks, NetLogic公司(RMI),Freescale(飞思卡尔半导体),EZChip科技,Xelerated公司产品线没,本人做L4-7等网络优化设备。希望有高手能够给予指导。

  168. pppoe 于 2010-08-25 2:31 上午

    站内一大半都是网络通信专家。。。

  169. MPLS 于 2010-08-30 7:25 上午

    没猜错的话小强为H -> X人士。

  170. MPLS 于 2010-08-30 7:39 上午

    学习,小强对NP很深入。
    请教HX什么情况下需要外挂TM?

  171. ASR 于 2010-08-31 12:42 上午

    有没有 人方便 发份 NP的 pdf 看看

  172. hwer 于 2010-08-31 6:18 上午

    网上可以找以前的ixp2800的文档看看

  173. chinomango 于 2011-04-25 3:41 下午

    新手,得益菲浅,不知陈首席有否总结成综述文章连接在哪?哪能看到50G+用X的设计?J公司是谁?谢谢。

  174. chinomango 于 2011-04-28 10:42 上午

    其实基本的架构这里的牛牛们都说了:
    1。传统多核,交互方法和fabric速度是瓶颈。多半只能用通用OS,8个核以上很少。100G以上很难。
    2。X的流水线,不大了解,如果所有应用都放在一条线上,相当于一条线同时生产多个型号的汽车。小强可以释疑一下吗?
    3。并行数组处理机,比如每个口用一个MPU,每100G一块卡再用xG互联。条件处理比X流水线可能还容易些。这个目前还没看到。

  175. chinomango 于 2011-04-28 10:43 上午

    其实基本的架构这里的牛牛们都说了:
    1。传统多核,交互方法和fabric速度是瓶颈。多半只能用通用OS,8个核以上很少。100G以上很难。
    2。X的流水线,不大了解,如果所有应用都放在一条线上,相当于一条线同时生产多个型号的汽车。小强可以释疑一下吗?
    3。并行数组处理机,比如每个口用一个MPU,每100G一块卡再用xG互联。条件处理比X流水线可能还容易些。不知有无人做。

  176. chinomango 于 2011-04-28 10:47 上午

    其实基本的架构这里的牛牛们都说了:
    1。传统多核,交互方法和fabric速度是瓶颈。多半只能用通用OS,8个核以上很少,100G以上很难。继续下去是功能块用硬核,一如MPEG用硬核ME,DCT。P4080挺典型的。
    2。X的流水线,不大了解,如果所有应用都放在一条线上,相当于一条线同时生产多个型号的汽车。小强可以释疑一下吗?
    3。并行数组处理机,比如每个口用一个MPU,每100G一块卡再用xG互联。条件处理比X流水线可能还容易些。不知有无人做。

  177. aaa 于 2011-06-05 11:39 下午

    请高人评价Broadcom准备在下半年推出的100G NP.C3.

  178. 狐说 于 2011-07-14 6:11 上午

    X的新片子出来了吧,小强有何评价?

  179. aaabbb 于 2012-04-05 7:42 上午

    现在在看看这个帖子,有意思啊。
    估计E的同志们,忙着应付客户,实在没人上网聊天呢。。。 倒是X的同志,找买家的过程中比较有空。。。。

    希望Marvell可以光大X

  180. lucia 于 2013-10-28 12:29 上午

    挖个坟
    时光荏苒
    如今ezchip半死不活,x门庭凋落
    俱往矣。。。

  181. Anne 于 2017-08-31 5:20 下午

    各位大侠好,现在这个NP4还用的多吗?