Cavium 与 RMI的简单比较

网络处理器方面目前比较主流的是cavium和RMI,目前讨论最多的也就是这两个,RMI进入国内比较早,国内RMI有HW, H3C等大厂商,cavium以hillstone为代表,不过据说华为等也开始转向cavium了。网络处理器的出现降低了国内安全设备厂商的门槛,因为国内所有网络设备公司目前都还没有能力自己研发芯片的。

要完全比较两款处理器,有太多方面需要说了,硬件方面包括指令集,core结构,总线, 各种加速的unit等,软件方面包括特定的os,sdk,还有开发门槛,开发难度等,商务产品定位方面那也不少。

其实cavium和RMI都是network multicore processor,这是不同于通用处理器的一个细分的市场,因为通用处理器市场已经被intel和AMD垄断,想到这个市场分一杯羹的梦想最好想也别想,想在处理器市场上有点作为,最好避开这个领域,专攻其他一些细分的市场,比如说嵌入式,音视频处理等,扯远了。Cavium和RMI的定位比较类似,但也不能说市场覆盖范围100%重合,毕竟两个不同的产品各有特点。

别的方面偶就不说了,说说处理器和软件开发的一些体会

Processor方面:

cavium 和RMI都是MIPS64 R2的core,cavium低端的50xx,高端的58xx以及68xx等,最高32core,1.5G,RMI最高8core,但每个core有4个硬件线程,每个vcore有独立的寄存器组,切换效率非常高,所以可以宣传说是32 vcore,最高1.5G。另外至于这个硬件线程的差别不知道有没有人评估过,Raza自己说能提高100% ~ 150%, 理论上cavium刚开始的时候要支持硬件线程也不是什么难事,是疏忽还是认为没必要,不得而知,不过我偏向后者。

指令集方面,cavium除了支持MIPS instruction set之外,还扩展一部分访问内存优化,CRC/DES/AES等加解密指令以及背后运算单元,RMI据说是没有这类似的扩展。另外,Icache/Dcache/L2cache等两者应该都差不多吧,没有去仔细比较。

Core之间interconnect方面,Cavium采用的是传统共享总线+L2 cache的方式,这个总线速度特别快,900Mhz下峰值可达500多Gbps;RMI的各硬件线程之间采用的是FMN ring传递,可以使得各个unit之间并行传输数据 避免冲突仲裁,FMN的宽度是64bit,所以1.5Ghz可以到90Gbps.

Packet的IO bus方面,值得提出的是cavium在在这个方面专门针对网络数据包做了大量的加速和优化工作,小的方面比如DWB, FAU等,包进来的时候有预处理,覆盖了包2到4层的检测,提取,校验等等,生成包信息,然后按策略调度到各个core,并且能支持同一个流上的包之间的order,包被处理完了之后出去的时候有自动port queue, 自动添加CRC等等;当然RMI做的也不少,基本上这些功能RMI也有,除了数据包order的支持。

其他coprocessor上面,cavium有IO bus上挂的有ZIP compress/decompress,另外有in-core的AES/DES/CRC等coprocessor,XLR也有内建的安全引擎,号称可以提供10G的加解密运算能力,不过据说实用也就2.5G,据说而已。另外这块我知道有一个cavium有的东西RMI肯定没有,就是DFA unit,上回RMI的FE过来推介的时候还特意调查了这个东西到底有没有需求的,有没有需求呢,我不知道。

其他的呢,也想不起来还有啥了,成本,功耗,工艺水平啥的貌似也不用去一一比较了。另外就是开发门槛,复杂度,扩展性等等了,multicore下面处处要小心,动不动deadlock就会死给你看,相对于这些core的同步问题,保证total performance 与core的数量成正比这就更需要实力了,如果设计不好,2个core的性能比1个core还差也不是没有可能,所以hillstone目前就系统稳定性和performance与core数量成正比这两点也是值得称道的。RMI里面的station, bucket能把人绕晕也有耳闻,没有真正搞过RMI,所以只能道听途说。系统结构越眩,越复杂,必然开发也就越困难。

发表评论

邮箱地址不会被公开。 必填项已用*标注