FP2网络处理器架构探究
作者 黑猫 | 2010-03-12 22:07 | 类型 弯曲推荐, 芯片技术, 通讯产品 | 101条用户评论 »
|
1、 FP2网络处理器的背景知识 在http://www.newelectronics.co.uk/article/22079/Pushing-packet-performance.aspx 公布了下述关系P2的技术细节： The p-chip’s role is to inspect packets and perform the look ups that determine where the packets should be forwarded. This network processor comprises 112 cores arranged in 16 rows of 7 columns – with the cores clocked at 840MHz. This contrasts to the 0.15µm process first generation 10Gbit/s FP1, whose 30 cores are clocked at 190MHz. Each processor is programmable and has its own microcode. Each row is programmed with a given task before being fed data packets, while packets from the same flow are sent in order. Thus, one row could be implementing multiprotocol label switching (MPLS) protocol tasks used to direct tagged packets between nodes, while another row could be performing IP routing. On the ingress path, two p-chips are used in series, along with the q-chip traffic manager. Though a single p-chip can process 100Gbit/s line rates, a second p-chip is included to provide additional processing for the broad range of current and future edge router processing tasks. 上文大意是： 1）FP2的NP有112个cores, 排布成16行7列。 2）每一行完成一种业务转发。如第一行做MPLS转发，第二行做IP转发。 而每一行又有7个Core，这说明它是典型的Pipeline架构，由7个Core接力完成一种转发业务（如MPLS转发）； 3）共有16个rows，说明有16条独立的流水线。每条流水线都可处理任何业务，具体是根据输入的包来决定。Each row is programmed with a given task before being fed data packets； 4）每一行的包能保证输入输出保序，说明它是严格的流水线，一个包只会沿着一条流水线走，中间不会切换到其它行； 5）再考虑到整个芯片要在16行之间保证顺序（例子，处理single flow IP转发），故需要一个输入分发模块和输出排序模块； 6）每个Core可以有自己的微码空间； 7）在Ingress方向，为了增强处理能力，将两个P串起来用。为什么要串起来？主要是增加查表次数； 根据对NP背景知识，上述信息已经很清楚描述了FP2网络处理器的架构：Pipeline stage，16条流水线，每条流水线上7个core。 2、 Xelerated网络处理器的背景知识 如小强同学所述，Xelerated的X11和HT320是很不错的网络处理器，转发性能有保障。下述链接算是基础知识，有需要的DX请先看看。 下面链接介绍，HX320有512个RISC core，是业界最多的芯片，无与伦比。第二多的是思科的SPP，有188个RISC Core。 http://www.slideshare.net/EJarstrand/service-density-by-xelerated-at-linley-seminar 下面链接是“A 40Gb/s Network Processor with PISC™”，介绍了X11的基本设计思想。 http://portal.acm.org/citation.cfm?id=1032450 http://spg.ict.ac.cn/paper/cassetDownload.action?cassetId=81043 3、 NP的两种类型：RTC和Pipeline 如果你想开汽车制造厂，有两种方式：手工作坊式和流水线式。 手工作坊式：招一个“四项全能”的工人，给他几张铁皮和全套工具，包括锤子、焊枪和几把刷子。然后由该工人完成汽车的所有工序。 只有一个工人，生产速率太慢，如何改进？答案是招几百个工人，每人分别发一套工具。生产速率也就提高了几百倍。 流水线式：伟大的福特发明了流水线造汽车。一条汽车生产线上有几百名工人，每人只发一件工具（不是一套），每个工人只做其中一件事，如张三上左轮胎，李四上右车门；所有人接力配合，也就造成出一辆完整的汽车。 流水线的发明，使平均每人的生产效率大大提高，也使工具的消耗量大大减小。既然流水线生产效率要高，为什么手工作坊造汽车还有存在的价值？因为这种汽车叫纯手工打造，全定制，每一辆汽车都是不同的精品，可作为经典收藏品。 了解上述造汽车的原理，再来理解NP的两种架构就很容了。一个标准L2/L3转发，可以分成下述动作：包头分析，IPv4查表、IPv6查表、MPLS查表、ACL查表、QoS分类、TTL减一、Checksum重计算、L2包头生成、流量统计等动作。 用许多RSIC Core来做包转发时，可以让一个Core完成上述所有功能，也可以让一个Core只完成上述一种功能甚至一种功能的小部分。根据Core的分工和组织方式，NP形成了两种典型的架构：RTC模型和Pipeline stage模型。 1）RTC(Run to Complement) 类似手工作坊式汽车生产厂。一个Core相当于一个工人，完成所有转发功能。所有Core并行工作，性能得以倍增。一个Packet只交给一个Core处理，不会转交给其它Core。一个Core有全套微码，但Core之间不需要交互。 该架构一句话评价：将方便留给软件人员，将困难留给了芯片设计人员。 优点：其编程模型对软件人员是最好的。因为是一个Core完成所有转发工作，故不用考虑多Core/多Thread之间的交付，微码编程与单Core无本质区别。微码可以任意跳转，甚至可以做复杂的函数调用（需要Stack支持）。 缺点：对芯片设计人员，不是好消息。 首先，每个Core需要放转置所有的微码（类似每个工人都要放全套工具），故需要的片内RAM较大，或者需要采用复杂的L1/L2 Icache；其次，每个Core都要去访问全部的外设（Co-processor），这样Core与外设之间需要一个巨大的Crossbar，该Crossbar在Top level布线很困难，长连线在整个芯片顶层乱跑。该Crossbar会成为架构扩展的瓶颈，甚至引起架构重写。 历史上采用该架构的NP举例如下： Internet Machine(year 2003, closed): 64个Cores(ARC)，单线程per core； Silicon Access(year 2003, closed): 32个RISC Cores，8线程per Core； Cisco SPP: 188个RISC Cores, 单线程 per Core； Cisco QFP: 40个Cores，4线程per Core 2）Pipeline stage 类似流水线汽车生产厂。将许多Core分成N组，组之间以流水线方式相连。流水线上每个Core只完成一小部分工作，多个core接力配合，完成所有功能。例如第一个Core作包头分析，第二Core作MPLS查表，第三个Core作ACL查表。这样，每个core只做一小件事，只需要一小段微码。所有Core的微码串起来，就是一全套微码。 该架构一句话评价：将方面留给了芯片人员，将困难留给了软件编程人员。 优点：首先，每个Core只有一小段微码（类似每个工人只发一个工具，而不是全套工具），故微码占用的片内RAM很小；其次，每个Pipeline stage只查一种表，故Core与外设之间不需要复杂的Crossbar；再其次，架构可扩展性比较好，只需要增加流水线级数，以及每级流水线中的Core数目，处理性能就可以倍增；最后，正如流水线汽车生产厂可以大大提高单位生产率一样，相同面积的硅片上可以放下更多的Core，从而提供更高的处理性能。 缺点：软件编程复杂。首先，编程人员要将微码拆分成一小段一小段，每段正好放在一个Stage；Stage之间，需要传送参数；需要保证每个Stage的负荷相当，否则就会造成流水线上有人忙死有人闲死。但IP转发业务千变万化，需要做到合理拆分其实不容易，特别是4层以上的业务如网络安全。所以，Pipeline的Core处理能力使用效率是要打折扣的。其次，一个Stage只能做一次查一次外部表，错过了本Stage，就只能等到下一个Stage查表了，而IP转发业务查表次数特别多（例如VPLS终结进入L3 VPN），所以常见解决办法是将多个NP串接起来用。有人提到将3个NP3串接在一起完成转发功能。总之，此类NP适合四层以下的高性能转发。 历史的Pipeline stage网络处理器如下： X11: 160个PISC Cores，分成5个stages，每个Stage有32个Cores； Ezchip NP3/NP4: 分成4个Pipeline Stages, 每个Stage有N个Cores； HX320: 512个PISC Cores，分成32个stages，每个Stage有16个Cores 需要指出，NP3/NP4虽然也是Pipeline stage，但其发性能并不高，这是因为其放的Core数目不够多。HT320有512个Core，而NP4有多少个Core？二者的运行频率相当。以前发表过的对NP4的评价，不妨再引用一下： 评价一个GPU的性能，主要看两个参数：内核和显存。同理，评价一个100G NP的性能，也是看类似的参数：Core, 以及Lookup Memory Bandwidth。根据这两点，不要指望NP4的性能。NP４集成了一个50G的TM, 用去了大量的Memory interface和Die size，留给NPU用的资源和DRAM就大大减小了。而Trio/FP2/SPP等高端芯片都是将TM和NP分离成２个芯片，可以充分保证NPU有足够的Die面放下众多高性能Core，以及众多Memory interface，从而保证处理性能。从过去业界对NP2/NP3的应用历史也可以看出：MX960用NP3给I-chip当配角用；C7600用NP3C给ES40单板的转发ASIC当配角用。 4、Table Lookup的延时如何处理 每个NP都配置了众多的外设，如做IP lookup的DDR2/RLDRAM，做CAR和统计的QDR SRAM。当一个Core开始访问外设到外设将结果返回到Core，可能需要50个Core时钟周期。在这50个时钟周期中，Core的ALU无事可做，Core处理能力白白浪费掉了，非常可惜。 解决上述问题，根据NP架构不同，有两个方法： 1） RTC模型：使用Multi threads 这里的Thread是指Hardware thread，不是指OS的Thread。一个Thread发出查表请求时，进入“go to sleep”，而当查表结果返回时，该Thread自动进入“awakened”。当一个Core有多个Threads时，当正在运行的Thread进入Sleep时，Core可以另外挑一个Thread来运行。 一个Core的thread多少合适？这取决了外设查表时间，以及外设查表频度和延时，以及Core的主频。一般而言，Core的主频越高，需要的Thread就越多；外设查表频度越高及时延越大，则需要的Thread数目越多。 采用Multi thread的NP： Silicon Access iPP (year 2003, closed): 8 threads per core, 32 cores Cisco QFP: 4 threads per core, 40 cores RMI XLR732: 4 threads per core, 8 cores Juniper Trio: 20 thread per core, 16 cores 2） Pipeline stage模型 做过转发ASIC的DX知道，在Stage之间的常做法是加FIFO，用吸收流水线之间速率差。Pipeline stage的NP，基本思想上就是从转发ASIC发展而来，只是将其中的Stage换成可编程的RISC。当然，也有人将其中的Stage变成可编程ASIC，如Juniper的Internet processor，这是题外话。所以，Pipeline stage的NP处理Lookup外设时延时，简单处理办法就是：在一条流水线上的两个Core之间增加一个FIFO SRAM，当上一个core发出查找外设请求时，同时将packet送入到FIFO SRAM中，自己就释放出来处理后续包；当外设查表结果返回后，packet从FIFO SRAM中输出，连同查表结果一起送给下一个Core。这种做法，与Multi thread有异曲同工之妙。位于Core中的包永远是“awakened”，让core的ALU充分转起来，除非微码编程人员的程序分段不均匀让某些Core太闲（这不是芯片人员的错,呵呵）；处于Sleep态的Packet包永远位于FIFO RAM中，不占用Core的任何资源。显然，这种做法的代价要比Multi thread小。这又是为什么Pipeline stage的Core数目可以做得比RTC模型要多的原因之一。 在一条流水线上，一个Pipeline stage通常只设置一个FIFO SRAM, 一个Stage就只能查一次外设。X11 NP共有5个Stage，共可查5次外设。一个复杂的IP转发业务要查10至20次外部表项，远远超过5次，点解？ 答案：内部流量绕一圈，5次变10次；将两个X11串接起来用，10次变成20次。实际上，Alcatel FP2也是同样做法。 5、 FP2网络处理器架构猜测 根据Pushing-packet-performance提到的信息，猜想结构如下：
一个P2共有7个Stage，每个Stage有16个Core。每个Stage外接一片RLDRAM或QDR供16个Core共享。 包转发流程： 1） Dispatch将输入packet分发到某条流水线上（即16个Row选一）； 2） Row中的7个RISC接力处理一种业务（如MPLS转发，如IP转发），每个Core只需要放一小段微码，而不是全部； 3） 每个Stage可支持一次外部查表；外部查表时，包离开上一级Core，进入下一次Core前面的FIFO； 4） 最后一个Stage处理完后，因为同一个Row的包是保证顺序的，但Row之间不保序。故需要一个Reorder模块来重排序； 5） 重排序的包有两种情形：如果处理完成，就输出；否则，就loopback到输入端等待再次处理； ,根据http://www.valleytalk.org/wp-content/uploads/2010/02/alu7750.pdf上的100GE单板图，Ingress放了2个P2串接，Egress放了1个P2，共有3个P2芯片。 每个P2有7个Stage，每个Stage支持查一次外部表，总共可以查7次外部表。参照X11的设计思想，P2应该是支持转圈，这样多转一圈就可以查14次。单板Ingress方向再放2个P2串接，就可以查28次外部表。28次查表与Xelerated的HX320之32次相当，一般情况下够用了。要是28次查表也不够用怎么办？答案：继续转圈，性能下降。 同时，FP1的30个Core，可以猜想组织为30 cores arranged in 6 rows of 5 columns。内部支持多转一圈，即有10次查表，上行方向再用2-3个P串接，则有20-30次查表。 可以，这种Pipeline架构的最大应用限制倒不是RISC core处理能力，而是查表次数。为了获得合适的查表次数，单板上需要串接P芯片。 申明：本文信息是基于公开材料Pushing-packet-performance的文字描述来推测，只能算个大概，不能当真。如果公开材料描述不准确（marketing语言），则推测也就不准确。 PS： 下面是Xelerated的NP架构示图。每16个Core组成一个stage；在两两Stage之间有一个EAP，EAP中有块FIFO RAM存放查找外部Table的Packet；当Packet的查表请求返回后，该Packet送到下一级Stage继续处理。 引自http://www.xelerated.com/en/dataflow-architecture/ The dataflow architecture includes the following components:
| |
 (3个打分， 平均：5.00 / 5) |
工具箱
本文链接 |
|
打印此页 | 101条用户评论 »
雁过留声
“FP2网络处理器架构探究”有101个回复
请教楼主：FP2不用像别人的NP一样需要增加用于IP转发的ASIC才能达到很多业务支持并且保持高性能，FP2到底在设计上有何过人之处呢？
很好很强大
FP2的应用是NP+NP,性能上与NP+ASIC是等效的。另外，P2将所有资源都用于NP，这比集成TM的NP3/NP4又要强一点。
多谢黑猫回复。
两片P2就能完成100G下SR的众多features（如果上行+下行，可能是4片），其他商用NP似乎都没有这个性能下的这么大的代码空间，FP2如何能做到呢？
1)Pipeline Stage模型在代码空间上有优势。一条流水线由7个Cores组成，每个Core只处理一小段业务。假设每个Core放8K微码, 则7个Cores相累加就相当于56K微码。
相比RTC模型，代码空间被放大了7倍；
2）关于商用芯片 vs FP2。我认为HX320性能大于等于P2，因为HX320有512个Cores，而P2是112个Cores；
3) 100GE单板是3个P2，见http://www.tektalk.org/wp-content/uploads/2010/02/alu7750.pdf
总结得挺好的，分成两类RTC和Pipeline很清晰。逻辑的人喜欢Pipeline，软件的喜欢RTC。
怎么才能平衡好呢？
非常好的文章。谢谢了。
56K如果是单片的话，再考虑evolution预留和分段效率，应该不足，至少需要两片P2串起来，不知道这种情况下是否还能保持单片时的性能？
3片的结构基本是因为转发模型的下行业务处理较少，用一片
RTC模型中单核的代码空间一般会比较大，比如至少32K，64K也正常，128K可能有点困难
HX320超过FP2有可能，但比CORES数应该不太成立，X11的116核也超过FP2的112，但是一个是20G，并且代码空间严重不足，一个是50G，代码空间远高于X11
HX320目前还没有商用，如果商用的技术表现超越FP2，那么对ALU可能会有一定威胁，期待HX320的实际performance
同意，除了Core数目外，NP性能还要受其它因素影响，如Core的运行频率、指令集效率、Co-processor的多寡强弱等。所以，并不能下结论Core数目多的NP性能就一定高。但在综合考虑上述各项因素后，估计HX320性能不比P2差。
2）每一行完成一种业务转发。如第一行做MPLS转发，第二行做IP转发。
而每一行又有7个Core，这说明它是典型的Pipeline架构，由7个Core接力完成一种转发业务（如MPLS转发）；
这段的翻译不太准确吧。应该是每一行独立负责一个报文（所谓的TASK)，互不影响。例如第一行在处理MPLS报文同时，第二行可能正在处理IP报文。而每行的各个core，是负责不同任务。比如core0做parsing，core1做转发查表，core3做qos、acl之类。很少有设计让某一行只处理某种特定报文的。
谢谢黑猫的好文。
几点不同意见和补充：
1. RTC的NPU还有IBM的Rainier，Intel的IXP系列。如果Bay的Chesapeak算NPU的话，应该是pipeline结构的。
2. 对纯粹的流水线结构而言，核数的增加其实对处理性能没有大的帮助。核数的增加可以增加pipeline的灵活度。而性能的提升，需要的是提高每个核心的工作频率。
3. 对于多核结构，核心数是决定处理能力的关键指标之一。但是更具决定性的是多核之间的总线设计。
4. 多核处理器对编程而言的易用性不仅仅对芯片设计不利，对芯片处理性能同样不利——每个核都需要完成复杂的任务，因此核与核之间的总线设计非常复杂。
5. 接上面，多个核之间采用的是相同的代码，因此大多数的多核处理器都采用了共享代码空间。所谓的RTC，我的理解是指每个核在运行时需要从共享代码空间根据runtime的状态加载所需的代码。预读指令同样会影响代码的执行效率。
6. RTC和pipeline的比较不能脱离NPU的应用环境。NPU是针对包转发的专用处理芯片，因此几乎所有NPU都采用了专门的微码作为编程语言，其目的就是为了优化包处理性能。因此个人认为，NPU应该优先考虑的是性能。
7. EZChip的NP系列不是纯粹的流水线结构。它的各个stage采用的都是多核。恰恰是这些多核结构影响了它的处理性能。
8. 外设的访问带宽是影响所有网络芯片的共同要素。如今的网络业务实在是太复杂了，绝大多数的表项都是放在外置内存中的。而且很多复杂的业务，如OAM，PTP，IPv6 lookup等，都需要一些外部协处理芯片完成——这点上Cisco/Juniper/ALU应该有优势，他们可以将自己的业务处理单元集成到自己的NPU中去——商业芯片往往缺乏这样的能力。
对于Xelerated的HX320，我个人是非常看好的。他的核心数比X11增加了3倍多，Application的flexibility大大提高了，再加上高性能……
>>1） RTC模型：使用Multi threads
>>
>>一个Core的thread多少合适？这取决了外设查表时间，以及外设查表频度和延时，以及Core的主频。一般而言，Core的主频越高，需要的Thread就越多；外设查表频度越高及时延越大，则需要的Thread数目越多。
你讲的是理想情况。实际是受寄存器的设计限制。 比如，一个Thread需要32个x32bit的寄存器，八个线程就需要8Kb的single-cycle-access空间。很难把它作大。
〉多核处理器对编程而言的易用性不仅仅对芯片设计不利，对芯片处理性能同样不利——每个核都需要完成复杂的任务，因此核与核之间的总线设计非常复杂。
核与核之间为什么要通讯哪？RTC的设计思想是核与核不通讯，靠共享的内存来解决通讯问题。
应该是核与内存之间的总线设计是其成败的关键。
〉 外设的访问带宽是影响所有网络芯片的共同要素。如今的网络业务实在是太复杂了，绝大多数的表项都是放在外置内存中的。而且很多复杂的业务，如OAM，PTP，IPv6 lookup等，都需要一些外部协处理芯片完成。
所以pipelined的结构是不能够在这种情况下用的。
一般来说，pipeline可以用在L2/L3的简单应用。L4以上的要回到RTC模型。
大家是不是过分关注NPU了。
我觉得100NPU没什么了不起，当有1.5GB RLDRAM作缓存时(200ms)，每个thread的余地是很大的。
最关键的是
1。 100G 的reorde如何做？
2。 100 的TM如何做？ 是否能做到100Mflows?
>核与核之间为什么要通讯哪？RTC的设计思想是核与核不通讯，靠共享的内存来解决通讯问题。
>应该是核与内存之间的总线设计是其成败的关键。
内存共享也是核间通讯的一种方式。为了共享内存，核与核之间需要有互斥机制。EZChip和IXP的互斥锁是许多问题的根源。
>所以pipelined的结构是不能够在这种情况下用的。
不是很理解MT的这个结论。Pipeline结构也是要访问外设的，为什么不能接协处理器？
>Packet Instruction Set Computer (PISC) is a processor core specifically designed for packet processing. A pipeline can include several hundreds (400+) of PISCs.
和小强讨论这个问题时，涉及到 the number of pippeline stages of X. 非常敬佩能把400级流水线搞定的人。但是这决不是一个好的设计方法。
#17， the idea of RTC is that each packet is processed by each thread and they can run in parallel without any synchroniziation and communication.
If there is any conflict (indeed exists), use atomic operations and issue them to the memory controller, like statistic updates.
In a word, avoiding the core-2-core communication in the RTC model as much as possible.
>不是很理解MT的这个结论。Pipeline结构也是要访问外设的，为什么不能接协处理器？
The assumption of the pipeline design is that the latency of each MEMORY access is FIXED (well known in advance). For example, coprocessor’s latency is fixed. However, for a DRAM access, its latency is unpredictable. If there is a data cache sitting in between, the latency is tottaly unpredicable. How to design a pipeline stage handling this case?
If DRAM access cann not be returned in time, the entire pileline is STALLED. In X, if a DRAM access takes more than the entire pipeline stages (>400 cycles), what would happen?
小小牛皮U：“很多复杂的业务，如OAM，PTP，IPv6 lookup等，都需要一些外部协处理芯片完成——这点上Cisco/Juniper/ALU应该有优势，他们可以将自己的业务处理单元集成到自己的NPU中去——商业芯片往往缺乏这样的能力。”
这的确是不错的idea，把原来外面ASIC的一些功能做成NP里的协处理器，有没有一些具体的证据或者information？我倒是觉得应该把已经非常固定的处理做到固化的协处理器里，比如基本的IP/MPLS转发等
Multithreaded：NPU不适合L4及以上处理，应该是基本的结论，这部分应该是多核的市场。所以一个复杂的路由器产品是融合了NP/ASIC/M-CPU/FPGA等多种核心器件在一个LC或者chassis中
>1)Pipeline Stage模型在代码空间上有优势。一条流水线由7个Cores组成，每个Core只处理一小段业务。假设每个Core放8K微码, 则7个Cores相累加就相当于56K微码。
相比RTC模型，代码空间被放大了7倍；
如果由I-cache， RTC和pipeline在指令空间上没有什么差距。这就是为什么QuantumFlow引入了两级I-cache.
>>）while packets from the same flow are sent in order.
〉〉每一行的包能保证输入输出保序，说明它是严格的流水线，一个包只会沿着一条流水线走，中间不会切换到其它行；
好像不对！如果这样做，那就是total-ordering了， 比flow-ordering强多了。
是否是每一个processor处理来自相同flow的报文哪？ 七个processor可同时处理来自七个不同流的报文。否者的话谈不上flow ordering.
RTC ：：=Run To Completion。我把文章修正过来了。RTC其实是一个OS调度的概念。通常意味着一个
while（1）
{
/* Do the 计算 ×/
}
也就是不存在计算能力的yield或者preemptive的东东。。。
RTC的时候，这个while (1)里面是否会存在类似接收消息的机制，以有机会被调开。还是说这个while(1)死死的霸占一个cpu？
RTC是一个算法层面的概念。到了CMP 和（或）MT的范畴，要区分各个层面的Yield。
例如，对Memory的读写，在HT的层面上，你其实是yield了CPU的计算能力。例如ALU。。。
随着EDA工具发展和工艺的提升，高端网络处理器设计门槛实际上是在下降，对于HW/ZTE这种国内厂家同样能做出这种NP。但评价一个设计是否成功，还得由市场说了算。
个人更欣赏
1）模块化设计的套片结构，通过不同搭配，你的芯片构成系统时能高能低。
2）业务的扩展性
个人觉得对业务需求的把握，能否快速加载新的业务到你的系统？从这个层面看，RTC(或者说pool)结构更有优势。
这里Juniper的人不少，
为哈大家不讲讲Trio chipset？
每个core有20个Threads,这个有意思，跟通常的设计不一样，能否解释一下？
回答MT的一些疑惑：
1）Pipeline流水线设计是比较简单的
“非常敬佩能把400级流水线搞定的人。但是这决不是一个好的设计方法”
HT320是将512个Core分成32个Stage，每个Stage有16个Cores。所以，在RTL设计和物理设计上，只需要搞定16Core的设计，然后再Copy&paste 32次。
2）Pipeline访问外设时延不敏感，可以支持各种协处理嚣
“Pipeline结构也是要访问外设的，为什么不能接协处理器？The assumption of the pipeline design is that the latency of each MEMORY access is FIXED. If DRAM access cann not be returned in time, the entire pileline is STALLED.”
请参考X11的设计，访问外设时，Packets是被扔到一块FIFO RAM中缓冲，不会Stalled流水线。如果时延大，只需要加大FIFO RAM，比RTC增加multi hardware threads来hold住这些packets的代价要小很多。Pipeline的缺点是查表次数有限，一个Stage只能查一次表，总的Stage数目有限。而RTC模型中，一个Core中的一个packet访问外设的次数理论上不受限掉，当然性能随着查表次数增加而下降。
>#25, RTC的时候，这个while (1)里面是否会存在类似接收消息的机制，以有机会被调开。还是说这个while(1)死死的霸占一个cpu？
没有机会被调度开，是一个THREAD被死死的霸占住。一个CPU里可以由多个Threads.
#29， 我佩服的是软件设计的人-）对于硬件团队，pipeline design 是他们的基本功，不会是要打板子的。
在软件设计上，你讲的divide and conquer 很难用上，因此十分具有挑战性。
加大FIFO RAM是硬件的设计方法，一旦FIFO的大小定了，一个DRAM的访问如何估算时间呢？
我看了你们的讨论，有许多感想。。。
如果有一天，我有这个能力，资源可以调度，我不把你们这些人才汇聚在一起，为大宋做点事情，我就不是陈怀临了。。。
大宋不缺这几个人，人家H/Z都奔40G去了，我们现在得跟着后面学。
to: 黑猫
There is third model, called functional pipelining model, which is in between RTC and pipeline.
Several cores form a pipeline stage and there are fast FIFOs linking each pipeline stage into the next.
一个stage查一次表是远远不够的，三次（L2/L3/L4）是基本的，支持查6次是必须
期待juniper TRIIO的分析
我在想为啥要查这么多次呢… 比如我把一些信息hash后压缩到一个320bit位宽的TCAM中, 一次不就可以L3/4一起查了么. 现在还有flexible的TCAM支持 160bit -> 640bit 变长. 那么就连IPv6的ACL也可以一次查完了? RENESAS已经release了一块?
VLAN要查一次吧
L3查一次：因为TCAM成本和容量考虑，路由表和ACL表示用不同的查找器
L4查一次。
这是基本的，业务复杂一些，就可能还有表需要插，比如BFD/FRR的时候，所以能支持6次是比较保险的
流量多绕一圈，一个P2有7个Stages可查14次，两个P2串接可查28次。—个HX320可查32次，因为它有32个Stages。
FP2的并行流水设计和思科10K上用的toaster是一样的，只是频率更高，core更多而已。思科为什么不选这条路，应该是再三斟酌的结果。
个人还是比较倾向并行NPU的设计。虽然说HX有512个core，假如其中64个负责MPLS业务，但系统里面没有MPLS流的话，那这些core就被闲置了。而且必须一开始预留有足够的core给将来业务，否则会导致代码结构的重构，因此实际可利用的core就更少了。所以512core的HX未必就比256core的新SPP强多少。
黑猫：多绕一圈，这个业务的性能还是保持一样吗？
转发业务＝查表带宽＋代码空间，无论Pipeline还是RTL，能平衡好两者之间的关系就可用。不过做到100G甚至更高的处理能力，Pipeline更容易做到，Core和Memory之间的互联毕竟简单些。
楼主猜测的架构中，最后的re order模块是不是只是一个简单的调度呢？对于Pipeline架构，没有re
order的必要吧，而且IP转发和MPLS转发之间似乎也没有保序的必要。
大家注意数通兄的发言，
老的SPP 188core(实际上是192个），250MHz.
新的SPP增加到256个核。
大家可以推算一下主频拉高到多少？
256核，如果再提高到今G的主频，功耗控制有何过人之处？之前CRS-1的傻大黑粗，功耗超大，体重大到普通机房750公斤的起重机都搞不定，成为业界非绿色产品的典型代表
#40,#42:按原文有16个ROWS，他们之间会乱序，故需要reorder模块。如果16条流水线设计包速率达到300Mpps，则绕圈还能线速。数通人说得很对，fp2与思科toaster相似。
如果16条流水线设计包速率达到300Mpps，这个是如果还是已经实现？目前的规格大概是多少呢？
很好很强大
思科的Toaster-2确实是老朽了，Toaster-2是2000年的产品，2.5G量级。主频125MHz, 4×4结构。
To 老刘
一般4片串联，组成8*8阵列。
FP1/FP2的流水线相对cisco toaster大体相似，但也应该有其过人之处，否则7750的业务能力表现就不会大大超过ESR10K。具体架构区别在何处，欢迎指点。
FP1是Timetra公司在2003年的产品，6×5= 30 cores @190MHz, 上行2片+下行1片完成10G转发业务。
好像后来的IOM2/3用两片就搞定了，当然也有代码空间限制问题，但基本能处理绝大部分业务，所以还是觉得很牛
FP1/2和IOM1/2/3如何对应？
那个应当是Toaster-3, 8×2结构，四片8个stage.
“FP1/2和IOM1/2/3如何对应？”
FP-1 对应 IOM-1/2
FP-2 对应 IOM-3
to HJ: 那您的意思是IOM1和2是一样的？不是一个10G,一个20G吗？
IOM-1和IOM-2都是20G，区别在于IOM-2在Egress方向多了一个P芯片，因此能够支持更多的特性。
一般的IP转发模型都是把业务更多的在ingress上，ALU7750不是这样吗？还是ingress已经是两个P了？
ALU7750 100G线卡，ingress两片p-chip，egress一片p-chip.理克客你是对的。
IOM-1：
ingress: 2个P1 chip，1个Q1 chip
egress: 1个P1，1个Q1
IOM-2:
ingress: 2个P1 chip，1个Q1 chip
egress: 2个P1，1个Q1
IOM-3:
Ingress和Egress公用2个P2和1个Q2
ALU FP2芯片组 。 100GE线卡 。7750/7450
目前NP似乎是AL最牛，到底AL在NP的那些关键技术做了breakthrough？
7750sr的qos好像很是生猛，而且其datapath也和首席上面的那个图有比较大的出入，我以前做芯片的时候还反复对照过其tm和datapath，可惜现在google不到那个胶片了
Xelerated的HX320不比FP2弱，无论是性能还是查表次数，甚至编程模型–pipelined stage。学习xelerated，可了解到此类架构的过人之处。
今天晚上花了一个小时细细地读了这篇文章， 基本上是研究生半个学期的学习内容浓缩在一片文章加六十二评论中。 太滋润了。
非常希望HX能超过FP2，只是目前HX还正式商用，所以还无法完全打消我的疑虑。
据说AL的下一代FP很快就出来，可以达到把以前的两片P2 double的水平
牛人太多，不好发表评论啊，总体感觉是，黑猫的评论其实结论是很正确的，至于论据有的时候说的不是很充分，但是了解X和FP2的人知道你的结论没错：）
to63楼，现在的研究生都干些啥啊？呵呵
黑猫能否对于NP+ asic的架构如何一起work大致描述下，我弄过asic，了解NP，但对于你提到的NP+asic怎么在一起转不是很了解，麻烦指教
就把它想成是自己山寨的一个cluster, 几个PC机+一个小交换机
例如CRS-1就是很典型的NP+ASIC架构, 它把转发的整个path分为 input chains 和 output chains. 然后呢, input做完了以后, 把报文拆成等长的cell, 每个cell头部做几个bit, 让ASIC做转发处理, 等转发到相关的output NP上了以后, 让output Np自己玩去…
不过说句实话CRS真的很xx(粗口)… 太重了, 设计要求承重我记得是一平方米一吨? 反正普通的办公楼别想了, 最多放底层或者车库玩玩…
NP+ASIC例子(其它厂家也是类似)：
http://www.juniper.net/tw/tc/products-services/routing/mx-series/mx480/#related-info
Each PFE consists of one I-chip for Layer 3 processing and one Layer 2 network processor.
> Juniper uses EZChips on all MX series line cards, not just -Q. In fact,
> the distinction between the original MX DPCs and the -E models is the
> rev of EZChip, with the -E’s having support for larger microcode (1.5KB
> vs 6KB). On regular switching/routing cards the EZChip is used only for
> framing and MAC lookup, all of the IP routing and QoS is handled by the
> I-Chip. I think you’re actually right about the -Q cards, there is some
> EZChip QoS functionality used there to implement the per-VLAN features,
虽说现在说自己能够做100G芯片（带业务的）的厂家也不少，但是大多还是处于预发布的状态下，而FP2早在2008年8月就正式发布了商用版本(SROS R6.1)…
架构推测的和我了解和猜测的基本一致。
目前有独立的input/output controller。
100M pps的情况下查表次数P2反而不如P1.
多谢楼主和各位，长见识了。
最近在研究x的NPU，光听厂家的一面之词感觉还是不够，有一些问题请教坛子上的大侠：
1 x的npu对线速的支持怎么样。
2 x的tm的功能怎么样
3 x的微码开发难度高不高，国内这样的人多不多。
4 价格相对bcm同等性能的asic相比如何
5 是不是可以真的做到完全可编程，可以任意添加feature
6 对于ram和cam的分配是不是很灵活
从aaa的发言，感觉是要开公司在中国，目前在芯片选型中ing。。。
另外，您的问题粒度太大了。TM功能如何？这叫问题嘛？：-）。
陈总也太高估俺们了，俺们只是一个普通工程师而已，只是选型的时候得到了一些信息，感觉x的东西还不错，所以想来这个论坛得到相对客观的对x的评价。
其实只需要一个很泛泛而谈的评价，希望有用过x的东西的大侠评价一下。到更具体的，我们应该会有他们的demo板进行测试的。
X的NP很强，经过了几个公司的市场检验。TM如何就不知道了，新东西，以前没有人用过。
网络处理器架构的演进之路其精彩程度不亚于通用处理器啊！
ALU 刚刚发布了基于FP3的Core Router: 7950 XRS，远超现有的Box:
http://www.alcatel-lucent.com/ip-core-router/
谁有更多FP3的剧透么。什么架构。多少core。interconnect？
FP3 有288 CPU‘s
好像FP3没啥大变化，还是NP TM 分离的
这篇2010的文章说“NP４集成了一个50G的TM, 用去了大量的Memory interface和Die size，留给NPU用的资源和DRAM就大大减小了” 但是Xelerated也在走集成 NP和TM的路子， 其实BRCM也有点类似， 但是FP3还是分离的， 到底是NP TM 分离好（技术好，但是价格贵）还是集成是个正确的方向（技术够用，价格合理？）
对于很多不用HQOS的场景，NP/TM合一利大于弊，应该可以提供更灵活的TM位置，而不受制于TM芯片在单板上的物理位置限制。当然，对于100G/200G/400G级别的芯片，是否还die space留给TM，可能是个问题。
http://blogs.nokiasiemensnetworks.com/news/2012/05/23/huawei-loves-nokia-siemens-networks-consulting/
华为这次真屌丝了
http://blogs.nokiasiemensnetworks.com/news/2012/05/23/huawei-loves-nokia-siemens-networks-consulting/
华为在高富帅白富美眼里，一直都是屌丝，虽然当暴风雨来临的时候，有些高富帅白富美死得并不那么高富帅白富美，比如NSN的未来，但一个屌丝如果要成为世人艳羡的高富帅白富美，3代常常是很有必要的
第二代。。富不过三。
如果不是用单NP实现上下行个人觉得NP+TM合一芯片就不好，上行其实TM没有什么意义反而把die size和DDR interface留给转发用好，毕竟上行的业务比下行复杂的多。
to EZ微码
没想明白， 上行为什么TM没有用， 除非你的fabric switch已经有TM了，因此重复了。即使这样， 也可以把TM放置在NP之前，当过载的缓冲，如果我记得没有错，EZ NP3应该有这样的案例
to aaabbb
1.因为目前来看交换芯片的处理能力肯定大于NP，所以上行交换处芯片不会出现拥塞，既然没有拥塞那么TM就没有什么意义了。
2.如果TM放在上行NP前面谁对的报文加TMID是个问题，感觉意义也不大。NP4虽然有了ICU模块，但是这个模块只能对进入NP后的报文进行调度（如果NP因处理性能不够已经产生流控，那么上游还是会响应流控丢包），所以感觉这个模块是个鸡肋。
dune交换网只有上行有TM，解决了队头阻塞的问题
要做好满足各种商业应用的QOS moble是个不容易的问题，TM在上行是需要的，如果NP集成的TM仍然只能在转发流程里的固定位置，那么意义就小多了，目前的领先程度fabric》NP>TM
to EZ微码 上行需要TM，我想阿土仔真想了，一般 EZ+ Dune的方案，从EZ这边看，上行就不用了。
NP4 的ICU就是因为没有配TM，因此才感觉没有太大的用处。 我在另外的一个评论里面，也说了类似的话， 没有大的TM缓存，调度就是个摆设。
to aaabbb
对交换芯片不熟，不过如果Ezchip+dune的方案如果上行dune没有阻塞的话要TM也没有意义啊，假设Ez最大处理性能50G，dune有60G这种情况？难道是两个50G的上行同时往一个50G的下行发流？这样也应该在下行交换芯片做TM比较好吧。
E2E考虑，仍然需要反压到上行的交换网或交换网前的TM做QOS
楼上正确。 交换网虽然能力超强，但是目的地拥塞，仍然能把流控传递到上行，最后反压源端。
To楼上，一般是出口目的地egress方向做TM来解决目的地拥塞, 而不需要反压到源端.
不知道CCC兄的系统前提和要求如何， 我们是特别做过一个机框内不同单板的下行反压上行的测试呢。
理论上端到端流控，只能在网络最源端–用户测丢包，否则丢包之前的操作就浪费了。
实际上，大家都是保障流控信号能发出，然后在自己系统的第一个分类处丢包
to aaabbb&理客
多谢两位的解释让我搞清楚了一个疑问，呵呵。
这种网络处理器和cavium以及Tilera的多核处理器的应用场合有哪些区别？谁来说说。
商用芯片好比九阳神功，只要资质差不多谁都可以练。练出来的功力有多少纯粹看资质。
独家芯片大多似葵花宝典或避邪剑法。练之前必须一刀把JJ切下才能练成绝世武功。切的越深功夫越好。只有练过功的才知其中苦与乐
>20G -> NP ，
20G->5G -> Cavium, Tilera
<5G x86
当然，界限随着年头在不停的浮动，但是大意是这个样子就好了。