网络应用领域，intel的路在何方
作者 zhoujin | 2011-07-19 17:27 | 类型 行业动感 | 147条用户评论 »
|
Intel将 处理器 的用途分为4类：应用、控制、报文 和 信号； 1. 在 应用和控制 领域，Intel的Xeon系列CPU已经是市场的老大； 2. 在 报文 领域（即网络处理器），Intel将推出Sandy Bridge，相比RMI/CAVIUM等，Sandy Bridge只是一个新人；不过，Intel的10G网卡（最新的网卡为了更好的支持IO-VM，具备了switcher功能）是推出的比较早的，再加上 其DPDK库，Sandy Bridge在网络数据包处理方面的性能值得期待；对于采用LVS等软件解决方案的公司，是个好消息； 3. 在 信号 领域，Intel将推出Knights Cornor（众核），是一个协处理器，类似GPU，可用于高性能计算等，预计12下半年推出； 从我作为一个互联网领域-系统工程师的角度看，Intel已经 or 即将推出的处理器很好地满足了需求； a. 互联网应用+分布式计算，采用Xeon； b. 4/7层设备+防火墙（均是soft），采用Sandy Bridge； c. 高性能计算+特殊需求，采用Cornor，如有类似FPGA的协处理就更好了； ps： 1. 咨询了演讲者Cornor是否支持自己编程，类似FPGA，回答是否定的，建议我们定制化服务器时解决； 2. DPDK-多核多队列、无锁队列、NAPI、Memory Per CPU 等； 3. 4/7层设备 — 控制和数据平面分离； 4. 虚拟化—VMDQ、SR-IOV； 5. 网络存储 — FOCE、 ISCSI； | |
  (6个打分， 平均：3.00 / 5) |
工具箱
本文链接 |
|
打印此页 | 147条用户评论 »
雁过留声
“网络应用领域，intel的路在何方”有147个回复
1. Knights Cornor（众核）里的每个核执行X86指令，是可编程的。但体系结构是不可改的。
2。DPDK的成功还有待考验。
3. Sandy Bridge要等到支持pci-e 3.0才能在网络应用中大放异彩。
题目很大，内容有点空啊。。。。
唯一的兴趣点是提到Knights Cornor，不知还有其他更详细的信息不？
Sandy Bridge 用于data plane？很少听说….Data plane 的CPU数据引擎更加重要， 单核的处理能力次之…
其他的说的太大了… 玩概念不是弯曲的风格..
目前的系列xeon 56xx，代号westmere，32nm工艺，增加了AES NI指令支持。
sandy bridge是下一代处理器，然后是Ivy Bridge, Haswell。
楼主，你是不是Intel的？如果是，你们是不是该给我们提供一些直接支持，我们可是给X86做了大量的宣传和评估！当然最好是给tektalk做直接支持
to panabit
不好意思哦，我只是硬件厂家。很多东西也是intel给我们宣传的。
intel在网络处理的市场不断下滑，也在做深刻的反思，连续收购了不少底层软件厂家，风河 大家可能更熟悉一点。intel毕竟不是省油的灯，dpdk要是真的很成功，我想对cvm和rmi将会是致命的打击，至少在芯片的货期上intel拥有绝对的优势，就看intel怎么去推了。
Intel已经签协议收购Fulcrum了!
intel之前也搞过交换，不知道这次能不能成。
DPDK我用过，里面有一些好的算法和网络包处理构架，但是内存管理完全是另一套，不太适合广大已成形的产品用。在x86上不需要实现什么数据平面，因为每个core都很有用，至于pcie-v3速率是快了很多，关键还是自己软件构架。
首席什么时候写个像浪潮之巅一样的东西啊？
网络对INTEL来说九牛一毛，如果INTEL把着眼点放在这里，INTEL就危险了，还是挽起袖子和ARM干仗把，没有移动市场的INTEL，就是没腿的大象。CAVIUM+RMI 中共产值还不够INTEL打个喷嚏。所以说INTEL反省做网络，我不信，如果是真的，只能说他脑子有问题了。
枪手的文章怎么也放在这
intel肯定不这么想，寸土必争才是硬道理，网络处理市场intel肯定要插足。不过intel的处理器主要为服务器和桌面来设计，倒看不出来有什么为网络考虑的地方,sandy bridge最重要的是增加了AVX指令支持，和网络有什么关系，我也看不出来。
就算他把现在做网络CPU的公司都replace掉，FSL, CAVIUM, RMI， TILERA。。。又能何如，总共没有多少产值，输掉一个APPLE IMAC,iphone比这个估计大n倍，小市场解决不了INTEL的问题。 switch这个方向其实比网络CPU的市场大多了，INTEL在这个方向投入比做网络CPU更靠谱
smart terminal的芯是intel的正道，网络intel/IBM都已经试水过，证明对这个级别的巨鳄，不是正道
intel瞄准的是数据中心市场, 这个重要的还是快速交换, 现在不管是软的还是硬的, 还没谁一家独大, 正是好时候, 他现在做的已经不是npu了, cpu, qpi, pcie3.0, nic, 整体方案, 白皮书能看出来一些, 可惜了dpdk只放给第三方细节设计和代码看不到.
为什么一定要分这么多类呢！其实很简单，sandy-bridge适合的做很多东西，不管是视频处理，还是网络处理等，就像一个大侠有300年的内功，干啥都没问题！intel 要的整个武林！！！
MOTO PPC的下坡路开始与APPLE在电脑里面不在使用PPC处理器，如果INTEL不能打败ARM（至少平分秋色）在移动，智能终端领域，INTEL哪里有钱投入新的产线来为网络应用服务，省了把，INTEL做网络，只能说是个顺带，所以INTEL的路不在网络
把市场分以下：
1。高性能计算
2。企业应用
3。多媒体
4。网络应用
4.1 switching and routing
4.2 L4 above
5。移动应用
5.1 手机
5.2 平板电脑
除了4.1 和5.1， Intel处理器应该是没有问题的。
http://download.intel.com/embedded/applications/networksecurity/323814.pdf
老早就看过这个博客了，楼主是博主还是来忽悠人的？
作为硬件厂家，我看到的是，原来早几年，网络平台基本还都是X86，渐渐的高端有用NP的了，后来NPU。技术成熟后，低端的也有用MIPS的，比如cvm的1到2核的cpu。价格可以很低，还有直接用arm做。目前只有中端的产品，还在用X86的比较多，我想只要软件厂商功底ok，可以搞定mips，传统x86迟早要退出网络市场。DPDK的出现，增加了很多不确定性。有可能是一个完美的反击。要不就夭折，平分天下的可能性不大，因为市场本来就不大。
DPDK增加的不确定性？说实话不敢苟同，Intel自己都对DPDK不怎么待见，不记得到底是Intel的哪个团队开发的了，但在Intel内部都不怎么当回事。很多厂商在用DPDK的时候，很多时候也仅仅当个SDK做为参考，或者作为开发加载环境使用。
但是，X86在PCIE3.0之后，一些原本的问题将不再是问题。要说一统网络设备是不可能，但应用趋势确实比较明朗，尤其是高端领域
回楼上，
正因为intel不当回事才具有不确定性，如果intel发力，还有mips什么事。DPDK本来就是一个全新的SDK，搭建开发环境，至于内存调用，任务分配那都是和mips一样的，都需要从底层搞起。在性能差不多，软件投入差不多，试问大家是用cvm，rmi还是intel。我想生产力就成了决定胜负的关键。
回楼上
你把SDK的作用看得也太关键了点。大多数厂商对SDK的态度，都是借鉴、开发环境快速上手为主，直接采用的可能性微乎其微。大家的做法都是，把现有的平台和驱动代码在DPDK环境上进行移植，基于Linux用户态或者Bare metal的方式，而这部分代码，大多都是公司级或者产品级别定制的。在这种背景下，Intel在DPDK上再发力，你觉得DPDK除了提供开发环境和借鉴之外，还能做啥？
反过来说，DPDP的存在，只能说提供了快速上手的一个可能，而这类东西基本上大多数芯片厂商都能提供一个类似的，或强或弱。
而关于芯片选型，涉及到系统前向兼容、软件研发成本、性能、功耗、芯片采购成本、老产品处理器切换风险等等因素，我实在想不明白，光一个DPDK能起什么作用。
怎么我看了上面几位发言，发现SDK最关键的作用，恰恰是降低后来者的开发门槛，让更多人可以涌进这个市场？
举个例子，没有DPDK以前，假如我是个小公司，想做个特定功能的x86 network appliance，那我既没有netscreen公司这样的技术背景，又没有Panabit这样的人才，基本是搞不成的。现在通过SDK的reference，相当于师傅给开了一扇门，我发现“哦，原来程序还可以这样写，在x86上也能跑出不错的性能”，至少原理性的思路不会错了。当然，产品化中的很多细致工作SDK不会去帮你解决，但它的科普作用对降低新进入这的门槛还是价值很大的
为什么要审核呢？
发言审核是什么意思
DPDK的讲座俺听过，是三个可爱的老外讲的，也仔细提了不少问题。对这东西还是明白一些。
它这个东西说实话，我觉得可以做的更好，至少我听的时候，这东西我是感觉不怎么样。恐怕大多数公司现在用的东西都比这个dpdk好用。他这东西除非intel发大力支持，做得非常完善，否则很难用起来。
楼上说的对，老的厂商基本不可能用。
但是新的厂商就敢用吗？我觉得找个对多核系统熟悉的业内人士，很容易就能作出比dpdk实用的多的架构。根本没必要去当intel的小白鼠。
个人觉得，DPDK上的Linux用户态还是值得参考的。
国内的厂家对Linux内核态掌握的较好。但是还有那家能在X86上做Linux用户态的开发工作哪？
DPDK，花了5分钟看了一下。这玩意实在是太没有创意了！
===
简单一点说：就是一个在core/thread上裸跑的开发环境(一个while(1)的大循环)，然后搞一个链接/加载工具。
loader要写的强大一点，什么smp/amp都要能够加载，不要想windriver 的wrloader，wrloader简直土鳖异常，居然不能支持elf 按segment加载，tlb也能不计算，代码段不能共享，程序空间(虚拟地址和物理地址) 都要求连续。
RMI的rmios多少年前的东东？2001-2002年的东东！
===
呵呵，其实所谓的fast path不是性能的银弹。为什么客户需要这个东东，说白了，是操作系统能力不够，写的代码不行。
就在linux上启动pthread，然后绑定，然后把报文直接映射到用户空间，不拷贝，性能不必fast path差！
自己跑vxworks amp，性能能够损失10%
===
但是话又说回来，自从RMI的rmios被华为接受后，演化成为了华为MCSS（当然也加入一些有用的feature，部分从windriver学习来的，比如symbol，c shell等等）
这就成为了业界标准，呵呵，要想进入华为，首先要支持MCSS。所以cavium也搞了一个fast path,freescale也搞了一个，好像名字还取得特别酷?
但是你看cavium/freescale土鳖不？看看MCSS loader能不能加载cavium/freescale vxworks 6.8????
===
【忽悠中…】都21世纪，难道多核的软件环境还一直停留在fast path上吗？这是不是一种返祖现象？是不是异常土鳖？
虚拟化，SMP, ccNUMA才是正道！
再说Intel cpu core性能，说白了，楼上的朋友，做过netlogic/rmi xlp832, cavium cn68xx, sandybridge 8core 的性能评估吗？
sandybridge的cpu core的ipc是牛逼，但是请注意：cpu微架构这玩意，简单地说，N年以来没有新概念，没有breakthrough.
请比较sandybridge和xlp832的ipc，可以自己实际测试。图省时间，使用benchmark能够部分说明问题.当然最有意义是—实际代码更靠谱。
intel强在工艺，cpu频率很高，但是功耗就是降不下来。给你一个100W的芯片，呵呵，那就只有挑战你的硬件工程师了。
===
所以，大家似乎有一种概念：只有Intel想进入网络，必然所向披靡。
这就是一种迷信，RMI xlp832,cavium cn68xx,还有freescale明年16核2thread的多核，就这么不禁打？
注意，我不提网络接口，不提报文加速引擎，不提安全引擎，不提报文保序。
只关注cpu core的能力（计算能力和访存能力），intel的sandybridge也就打一个平手。
然后再谈一个更重要的指标： 每瓦性能，
Intel怎样应对这个问题。
===
BTW, pcie3.0就能够解决所有网络接口问题？
sub-interface/vc，报文前端解析分流，报文报序,DMA性能就被华丽丽的无视了。
再说Intel的主业：
进入移动市场，这才是重中之重！
前天intel的财报不错吧？但是股价还是跌，marketwatch上引述华尔街的评述— 大家都清楚，pc桌面市场未来必然萎缩。
什么云计算，哎，就是浮云！ 对于intel来说，云计算能够让服务器的芯片市场突然变大？
低功耗，移动互联网的计算支持，才是Intel真正需要警醒的！！！
win8支持arm，这才是intel的绝地警报。
apple拿不下就算了，M$为了应对apple的竞争，这次win8对arm的支持可是玩真的
最后总结陈词，
呵呵，做网络的话，不要去Intel，没前途—不是公司主业，迟早没戏。去rmi/cavium/甚至fsl都更靠谱。
不过，坦率地说，去fsl做网络，也是日薄西山。所以，cavium/rmi才是正道。
>这就是一种迷信，RMI xlp832,cavium cn68xx,还有freescale明年16核2thread的多核，就这么不禁打？
晒一晒他们的LLC有多大，就知道禁不禁打了。
Intel的处理器是多用途的，做网络应用要进行相应的软件优化工作。 目前性能的瓶颈口不在硬件，而在OS上。用通用Linux来评估sandybridge没有实际的意义。
比如，不做优化，Intel82599+Westemere 大概能处理2Gbps的最小包。 经过NIC驱动的优化，能达到14.8MPPS的10Gbps处理能力。
>DPDK，花了5分钟看了一下。这玩意实在是太没有创意了！
===
>简单一点说：就是一个在core/thread上裸跑的开发环境(一个while(1)的大循环)，然后搞一个链接/加载工具。
这有点误导读者了，你说描述的只是DPDK内核态的东西，DPDK还包括Linux用户态的应用。
我和你一样，对DPDK的内核态不感兴趣；但推荐大家关注一下把内核态移植到用户态的方法。
其实不是INTEL大哥不能做的更好，而是这个市场小的大哥看不上呀。例如AMD，从芯片角度，他最像INTEL，可一直是失败，在CPU领域混，第一条就是不能和INTEL做的一样呀，多远，找到自己的地方蹲着。做个几百个M, 就不错了，当然INTEL要天天盯着这些对手打，只能说人多的闲着没事干，在捡芝麻丢西瓜。总体来讲CPU的门槛不是越来越高，而是越来越低，也不要说龙芯不好，海斯的多核不行，在给几年这个中低端市场可能就不是美国公司混的了，这只能去做高端，超高端。
Netlogic的xlp832就是一杯具，还是看好Fsl的T4。Fsl相对来说更靠谱些。
Cavm 的cn68xx神吗？我觉得太神了！这可是65纳米下的32核。哈哈哈哈。。。。。
Intel牛吗？当然牛，而且是很牛。财大气又初。sand bridge/westemere计算和访存性能以及qpi芯片互联牛B吧，可它有它的问题。
对arm和苹果，intel你准备好了吗？
to 35.
DPDK有那么弱么？我不是很相信，5分钟就能知道其架构？原来有幸看过DPDK，我觉得其思想挺好的，最基础的框架也很好，据说和panOS的架构很像，再说，DPDK也不是在内核态，不知是否真的看过DPDK，DPDK中的内存管理是精华，绝对值得学习的
楼上细说啊。不要放烟雾蛋。
to aaa, FSL t4在哪里？是不是在ppt里面？
来点实在的，fsl现在有没有和cn68xx,xlp832竞争的产品？
实在一点，我们不玩虚的。要说ppt里面传说的产品，rmi有xlp9xx,cavium有28nm的cn7xxx。
===
我说fsl日薄西山，你了解一下fsl最高端的P4080和cavium的哪款产品竞争？和rmi那款产品竞争？
fsl当前最高型号只能和cavium/rmi的中端产品竞争，当然你非要说价格有优势—我也是没法反驳你–反正价格都是商务谈出来的。
我靠，楼层竟然变了。我是让aaa不要放烟雾。。。
看了xlp832的资料怎么没有看见功耗的描述。
看了xlp832的资料怎么没有看见功耗的描述。
其实在技术上可以说是大通的，DPDK的那一套内存管理从某种意义上将可以理解为intel的mips。
但intel有的是工艺，有的是生产力，知道现在cvm和rmi的货期有多长吗？少说3个月。厂家可以等，市场等的了吗。
当年港湾在交换领域能起色不少，不是因为用了最牛逼的技术，而是用了最实用的技术，在挑芯片时货期是一个非常重要的非技术性参数。足以影响到市场的占有率。
传统X86，在网络市场也占有一席之地，dpdk无疑是锦上添花的事情。市场只会更好，没有理由继续变坏，至少在技术上，有了和cvm&rmi平起平坐的机会。剩下的就是市场运作，这是intel的强项。
就像cvm和rmi谁的技术更好，我想很难定夺。客户选择什么芯片有客户的考量。更多还是看市场运作和物流，价格，技术支持，这些附加条件。
intel也有劣势，现在想搞多核的，都已经在mips上花了不少心思，再转型从零开始去搞X86，可能性大不大就不言而喻了。
市场是检验芯片的唯一标准。所以现在下结论，我觉得还为时尚早。
想下载dpdk分析分析,做voiprelay用,苦于不是特权用户,用不了,如有好心人发给我,将万分感激!!wanggp0@163.com
楼上各位反复提到DPDK，请教一下，如果不联系Intel，还有获取这个开发包的方法么？比如哪位有，发一个？？
to 各有优势，
还是当年港湾交换的兄弟，握手哦。
近一两年来看，
还是rmi/cavium第一阵营，然后fsl/intel第二阵营。
moto想当年多牛逼，前两年相当地惨，最近又靠android打了一个翻身仗。
nokia想当年多牛逼，现在破落成什么样子了。
北电….
所以，我想说的是—在通信/it/半导体行业，我们就没法去推测5-10年后的情形，就当下说当下，最靠谱。
什么ppt,什么路标，什么下一代，哎，就当厂家表示合作的诚心吧
/////比如，不做优化，Intel82599+Westemere 大概能处理2Gbps的最小包。 经过NIC驱动的优化，能达到14.8MPPS的10Gbps处理能力。////
很高的数据。。呵呵，不过我告诉你，单比io能力的话，832一个核，带保序，就可以做到24Mpps，你是不是很惊艳？ matrix说的一点请关注，“sub-interface/vc，报文前端解析分流，报文报序,DMA性能就被华丽丽的无视了”
还有弟兄在捧FSL，贬RMI 832！：－）。简直是乱了套了。很难不相信不是FSL的托：－）。
832是一个指标性的意义的芯片。我很看好滴。。。。。。非常期待基于832芯片的系统问世。。。
我主要是想看看ccNUMA在通信系统中的应用。这是我长期以来的想法。
非常赞同matrix的意见，这个行业更新太快了。
另外，捧FSL，贬RMI 832的，从正常的逻辑来看，肯定是FSL的托。
XLP832多少钱呀 500USD能搞定吗？
有一点不明白，RMI这么好为什么不能上市，而被贱卖，CAVIUM 这么牛为什么最近投入都在消费类芯片的相关开发和收购？ FSL这么烂，还能IPO，INTEL一天的销售额估计比RMI一年做的生意要多。INTEL有INTEL的负担，其他人有其他的优势，不能一棒子打死， 例如RMI XLP832很好，但有一个芯片性能是差些，但功耗小一倍，价格三分之一，你说客户会选谁呢？
很难说XLP832不好，只能说netlogic的支持不到位，市场营销没有cvm好，才导致不少企业转投cvm，华为就是其中一家。如果只谈技术的话。正如matrix说的一样rmi/cavium第一阵营，然后fsl/intel第二阵营。
理论毕竟是理论。想象是没有说服力的。cn6880和XLP832，我们都有在做，规格几乎一样，都是针对ATCA-40G的平台做的网络处理刀片。2011Q4会出来，到时PK一下，看数据说话。
其实大家都忘了TILERA， 自己说啥都不算，附件是Facebook刚发表的一个white paper. 里面有TILERA cpu和INTEL, AMD的对比。 http://vdisk.weibo.com/s/u0FQ/1311644588
什么是指标性的意义的芯片？不理解。谁知道请告诉大家。
832这么拽，敢问都谁在用？思科华为在用吗？
to Sting:
不过我告诉你，单比io能力的话，832一个核，带保序，就可以做到24Mpps，你是不是很惊艳？
—-
怎么理解这里“单比io能力 一个核 24Mpps”这段话，是实测的还是理论计算的，若是实测的能否透露下是什么条件下测试的，网口裸转 or L2 or L3？多少条流？因为数据实在太过惊艳！若是实测值，那么我想我做的东西可以扔到垃圾堆去了。
to matrix：
做过netlogic/rmi xlp832, cavium cn68xx, sandybridge 8core 的性能评估吗？
—-
由于我也对这三款（特别是前两款）cpu的性能评估比较感兴趣，如果matrix大大做过对应的性能评估的话能否分享下，并注明评估模型，谢谢。
to changjia,
对于H和Z来说，只用一家的产品，显然不现实。
对于支持来说，特别是新产品导入阶段(xlp832去年10月sample,cn68xx今年4月sample)，太多客户需要响应，所以…….
to System,
对于上市问题，rmi买个netlogic 250M，不算贱卖了。cavium 07年ipo时候多少钱？ 270M。当然如果说09年多核网络处理器的市场比07年更清晰，理应价格更高，这是没有问题的。
一句话，多核网络处理器这个细分市场，实在太小，不能用brcm，更甚至intel的量级来衡量cavium/rmi
对于fsl的上市，
莫有记错，当年fsl被黑石收购的时候，和brcm的市值差不多，大概在15-17B这个级别，现在fsl的市值才多少？ 4个billion
再说intel的销售额和cavium/rmi的销售额进行比较，就没有任何意义了。
你应该比较的是intel在网络多核处理器的份额和cavium/rmi/fsl的比较。
===
例如RMI XLP832很好，但有一个芯片性能是差些，但功耗小一倍，价格三分之一，你说客户会选谁呢？
— 这个我同意，性能只是一个因素，功耗很重要，价格更重要。甚至商务能力特别重要。但是弯曲毕竟是一个技术网站，谈性能功耗有意义，谈技术支持有意义，价格和商务估计不是这里的主题。。。
to peter Liang,
数据很不错呀，一个问题：intel 4core到8core的性能scalability怎么这么差？
如果能够确认intel有AE/FAE参与了这个测试，并且也在软件中也尽了最大能力优化的话，我看tilera前途无量！！！
>单比io能力的话，832一个核，带保序，就可以做到24Mpps，你是不是很惊艳？
From netlogin:
—————————-
A Packet Ordering Engine (POE) supports packet ordering for up to 64K flows.
—————————
832上有硬件把报文分到核上去，每个核上有四个线程，每个线程处理6MPPS是可以理解的。10年前Intel 28xx就能做到14.8MPPS。 十年后翻个番很正常。
能保序的flow数目小了点，无法做到1M flows， 不知道是如何在实际中使用的？ RegEx Engine （Cavium 的同样）所支持的规则数目有限，使用起来有一定的限制。
每个处理器都有它的用途， 想和X86比，就要比L4-L7的处理能力。 没人要用X86做L2/L3的东西。
#60：
那种Intel8-cores？ 如果是4+4的配置，你就要和两个 XLP832 + XLP832 比。看看scalability 是不是一样涨不上去。
其实每个处理器说碰到的问题是一样的，只要是非处理器之间的通讯，对软件的优化都是极大的考验。
不知CC-NUMA在两个XLP832之间是否有效？
大胆的估算一下： Sandibrige 6-核 （12个线程）的性能和8-核 （32个线程）的XLP-832估计是差不多！
假定系统是10G的firewall, 要处理1M flows。 这时系统的性能基本上是取决于L3-cache了。XLP-832 有8M 再加上多线程弥补一下不足，估计和12M或15M的Sandibridge有一比！
XLP832上的报文包序的协处理器，估计都用不上了！
to multithreaded #62,
我在评价tilera的文档（tilera在facebook，和intel,amd pk memcached性能）
我看到tilera单芯片性能很好，然后4个tilera64性能也是线性增长，但是4-core Intel Xeon L5520，从单处理器188k到dual xeon 200k，性能却几乎没有增长。
tilera这个文档不是PK ccNUMA.
===
ccNUMA自然不好做，cache一致性要在芯片间完成，又要保证性能，那是相当地难。
to multithreaded #63
看你的回复，你的业务主要pk L3 size/latency，那说明你业务的L1/L2 miss很大。
1.报文是否配置DMA到内存的同时，同步DMA到L3 cache.(intel有这个功能，832有，fsl也有，呵呵，大家都有。。。)
2.你是在L7业务，要做深度报文扫描。然后也看到评估过cavium regex引擎，是否满足需求。你认为cavium regex限制很多，可以考虑rmi xlp316（集成netlogic的第四代dpi引擎），也可以考虑LSI acp34xx（4核的powerpc，这个powerpc内核从IBM买过来的，性能一般，但是他的dpi引擎应该还不错，是从当年tarari收购过来的，做得比较早 ）
to Matrix #65
1) it is called the DCA feature. However, it is NOT useful in practice for 10G+ processing
2) There are many DPI applications. Regular expression is just one simple case. Even for that simple application, most of engines cannot handle more than 1,000 rules or a few of “bad” rules with many *.
3) Extra co-processors will increase system cost and complexity and instability. Therefor, X86 has advantage since everything can be done in SW if one knows how to optimize multi-core based X86.
4) I have stated many times, no one recommends X86 to be used in L2/L3, period.
X86以及PPC等CPU从设计之初开始就是为计算型业务应用的，所以在L4-L7层应该是有优势的；但在L2/L3的高速转发型应用，一定要有针对性的设计，比如超多的硬件core和thread和针对包转发等用到的协处理器等，所以ASIC/NP/RMI等更适合。
比较一些这些处理器的specification，大体就可以发现这些基本特点
Matrix, XLP 832一个Core可以处理24Mpps，这个数字挺不错的，问一下，Core的主频多少？另外，2个Core，3个Core，……的扩展性如何？
to panabit, 潜水弟：
单核24Mpps的数据是实测出来的，主频1.2G，A0样片，64字节小包，L2环回测试,24Mpps，如果1.6G的话大概到32Mpps；因为基本一两个核就超过20G测试仪器限制了，因此此处加速比没有结果。 后来又测试了100K流的L3转发数据，5核加速比估计在90%左右。
不知大家关注到没有，其实大家的思路都是一个意思，只是相互理解上存在一些偏差；
就像理客说的，对应网络应用来说，实际上存在两种不同的应用模型，一个是L2/L3快转业务，这是更多的是在强调IO能力，而这才是RMI/CVM的强项，也是ASIC存在的价值所在，这时多线程、保序、前端解析等硬件加速能力可以充分的派上用场； 而x86用DMA做转发，简单计算一下一秒DMA可以协商多少次就清楚了，而且这还需要硬件加速，把配套的所有芯片都放在一起，才能跟mips的一个处理器相比；功耗效率可想而知。
而另一个就是L4/L7的应用场景，这也是multithreaded 更加关注的业务场景，这里当然对比IO能力是肯定不够的，这里更加强调类似于x86的强大的计算能力、超深流水线、完美的第三方支持。 在简单L2/L3快转上，832大概可以做到1.8的IPC，而snb的IPC大概在2左右，两者基本可以相当。但是如果每包指令数超过10k，甚至只有5k，这个数据又会变化n大了，intel的优势会更加的明显
每个处理器都有自己的特色和优势，有时候融合，可能也是个不错的选择，各取所长，例如用TILERA的CPU+ Sandbridge. TILERA的CPU做多核擅长的，SB做x86擅长的。 当然如果软件架构非常适合多核，那要SB也没有必要。
70楼：L2环回测试，数据还是到wire上吧？
没错，经过加速器到CPU，交换源目的MAC后发送出来，双向速率
简单L2/L3对应switch(LAN)/Core router(WAN)，这恰恰不是CPU的市场。在LAN/DC里，BRCM这样的专用芯片功耗和成本优势更强，RMI/CVM插不上手，当然X86就更别提了；在WAN里，貌似几家大的系统厂商都自己定制。
复杂的L2/L4(VPN/FW)，以及L5-L7才是所有CPU解决方案的战场，它们一般涉及对payload的处理，计算量极大，最好能有内置协处理器/加速器。这类设备往往在边缘，IO倒不是主要矛盾，还是计算密度问题，但纯X86 CPU不一定就有优势。不过若能把它的新特性用起来，比如长指令、加密和不进位乘法加速，尤其是SNB内置与CPU共cache的GPU，还是有望和集成了协处理引擎的RMI/CVM一较长短。
to 根本不相干 #76
这是专家意见！！！
L2/L3等简单业务，就不是rmi/cavium/fsl/intel等各家处理器的市场，这个市场是brcm交换套片的市场。
诸如业务路由器/安全等需要支持多种网络接口，需要做NAT/FW等相对复杂业务，NPU和多核处理器可以进入这个市场。
对于更复杂业务，NPU就不合适了，这个候，多核处理器是唯一选择。
这个涉及一个系统设计的问题，asic –> fpga–>npu–>网络多核处理器 ，吞吐从大到小，可编程性从小到大。
所以对于一个通信系统，需要全盘考虑计算放在那个节点上完成。
===
我看这里的兄弟很大一部分是数通和安全方面的专家。其实对于无线（包括核心网和基站等等），存储等方面，上述处理器由于一般都加入相应的加速引擎，这也是特别关键的目标市场。
to multithreaded #67
2) There are many DPI applications. Regular expression is just one simple case. Even for that simple application, most of engines cannot handle more than 1,000 rules or a few of “bad” rules with many *.
—- cavium的regex不应该只有1000条的限制，它可以spill到memory。但是cavium限制应该是规则库爆炸问题（rule数增加，导致规则库指数级别增长）。但是据说cn68xx上有所改善，这个可以评估。
对于netlogic dpi,第四代dpi引擎，同样没有规则数限制(可spill到L3 cache/memory)，然后按照前三代的经验，netlogic解决规则库爆炸问题有独到之处。
tarari(LSI)的dpi引擎是cisco一拨人出来搞的，对业务理解能力我想应该是有一定保证的。
===
BTW,我同意你对当前商用dpi引擎的理解—确实存在限制较多，性能无法恒定（严重地受到规则库影响），总体感觉没有安全加密引擎来得自然。但是另一面来说，怎样把现有的软件架构中，合理合适部分offloading到商用dpi引擎，增加产品竞争力，这是厂商竞争力的关键点。
===
另，坦率地说，我不是特别理解“Extra co-processors will increase system cost and complexity and instability. ”
举一个简单案例—比如说ipsec的加解密都用x86 core来完成？
如果这样可以的话，intel就不用推它的Cave Creek?
感觉湾网搞网络安全的居多。
All those external co-processors are very expensive. For example, how much does it cost for a LSI acp34xx?
In addtion, don’t blindly think any one from Cisco is better since Cisco is not good at L4-L7 applications at all.
Once the DFA generated is so large to be spilled into memory, a RegEngine has the same speed as any SW solution since the bottleneck is transformed into the memeory access speed. That is the reason that I say all those co-processors are good for small-scale applications and but good enough for any real and large-scale applications.
to 根本不相干 #76 / matrix #77
我提到的L2/L3转发业务模型，就是在无线基站、控制器、xGSN等接口板接入侧的应用场景；单一IP接入，报文根据五元组解开后，重新封装IP头进入系统内交换。
这种场景跟网片基本没有任何关系，接入最大的难点在于L2/L3的高速转发和TM的支持，这也是无线领域使用mips处理器最多的场景。
to #81:
How many classifications rules does the system need for such a 5-tuples classification?
Are there many wild char * in those rules?
一般的路由器，防火墙之类的，ACL到1万条是很高的要求了，一般测试最多就听说过1万条。
接口板看到的五元组基本就是源目的IP、源目的Port、协议ID；
一块接口板看到的流基本在10w条以上，一个用户的一个连接是一条流；
一个RNC系统接入最高是100w用户，当前规格基本都在二三十万条流，当然这是全系统两三对接口板完成的任务；
to 80,
Once the DFA generated is so large to be spilled into memory, a RegEngine has the same speed as any SW solution since the bottleneck is transformed into the memeory access speed.
————————–
I think you have misunderstood the conception-memory, which is sorted as sram and dram. Your judgement is right only when dram is used.
By the way, I wonder why you can read but can’t write in chinese
to sting
你是说只处理outer header的5元组，但IP payload里的tunnel信息无需处理，我理解对吗？
不过这种情况，它并不属于简单L2/L3转发，因为它的决策既不是MAC，也不是IP的逐包转发，而是类似状态防火墙的流转发。它的需求是海量流表处理能力，属于我后面提到的复杂L2-L4类别，对硬件的要求类似openflow交换机。
这种情况下哪种CPU表现好，跟具体算法选择有一定关系。如果为了追求表空间利用率，而选择一些较复杂的变种哈希，其计算密度仍然是超越IO吞吐的主要矛盾（尤其是你是无线的场合，还是偏Edge的，流量跟固网仍不是一个量级）
#85, that is my point since I have designed such a RegEngine.
Intel SRAM Cache
DRAM DRAM
As long as a regEngine do a spill, it will have the same speed as any SW solution using general-purpose CPU.
Please note CPU has very large cache now such as 24MB
敲中文太慢了，对不起！
The formating is terrible.
A co-processor’s internal SRAM is equivalent to the cache system in a general-purpose CPU.
#83 and #84.
Thanks for info.
If most of rules have exact values, then it should be easier to handle 10K+ classification rules.
The difficulty comes from those rules that have many wild char *, which makes classification hard.
I guess for 1M flows, creating and searching such a big table becomes a very interesting topic, which is the problem I am working on.
>一个RNC系统接入最高是100w用户，当前规格基本都在二三十万条流，当然这是全系统两三对接口板完成的任务；
If one can use ONE board with 1-2 Intel multi-core processors on it to handle 10Gbps linerate and support 1M flows, are you interesting in this solution?
Any power concern?
#86, I could not agree with you any more
The performance for RNC applications depends on the algorithm used. Ones can use MIPS + co-processors and the others can use Intel/AMD multi-cores.
Othe facors will kick in such as power, cost, area (one chip vs. mutiple chips) etc. …
@86，根本不相干：
每包指令数大概1k，你还认为是算法密集型么？
@91, multithreaded：
64字节包10G线速的场景下，需要20M+的处理能力，处理单元功耗需要限制在80w以下；如果832 pk x86(含桥片、其他硬件加速？)，孰优孰劣??。。。
64字节包10G线速是指Ethernet的报文吗？ Ethernet在10Gbps下的最小报文数是14.8MPPS.
不知20M是如何计算出来的？
如果用X86（Westmere或Sandbridge）一个6核处理器，应该是能搞定的。注意这里不用任何的协处理器。
面板出10G有多个口，做主备使用，单一端口10G线速是14.8Mpps，其他流量预留给备用端口使用。
能否请教一下，能搞定是怎么计算出来的？
单从计算能力上看，我从不怀疑x86搞不定，但是我怕x86搞不定的地方在于这么大流量的IO处理，全是桥片在折腾DMA搬移。。。
Please refer to the recent posting in
给力吧，x86（1）——11月10日Panabit测试记录 :
很早就看过，流量不大的同时CPU也不高，这时候IO不是瓶颈
INTEL的计算能力确实无人能比，做复杂网络应用不错，DPDK就是用户态的linux网卡驱动，多队列，多核分别处理多个网卡的流量，分流我觉得肯定是个瓶颈，intel要进入这个市场，还是得专门开发网络加速硬件，不要再用pcie了，不过别个在这个市场只是玩玩而已，重视终端市场才是王道。至于832和68xx实测相当于前一代的3-4倍性能左右。832的核总体还是不错，虽然还有一些设计上还可以提升的地方，不过做的太复杂了，核数做不上去，和6880的32个核比，^_^。fsl还是有价格优势的，不过产品出的实在太慢了
楼上对多家厂商的评价还是很中肯的。句句都比较在理。目前的重头戏无疑是6880和832.
TO Sting
每包指令1k，那么64字节10G线速就需要14.8B Cycle。以Xeon 5645 6核为例，差不多是14.4B，基本上把CPU占完了。而单纯完成10G转发，对CPU的消耗远远达不到这个程度。
根本不相干的分析很精准，是不是此类应用都是用流表快转，或叫fastpath，首先建流，然后用hash差流表，那么对于非首包，100条指令就够了，如果是per packet转发，按照您的分析，通用的没有内置硬件辅助引擎的多核CPU是不行的
to #99: How do you come up 14.88B/per cycle?
to 理客
我暂时不清楚Sting的1K来源，我是根据他的预设条件做的初步分析。但我的确认为，对于边缘设备（不论SP还是Enterprise的Edge），由于业务规则的复杂多变，fastpath是一个较好的选择。
由于摩尔定律，当然很多事情并不是说CPU绝对做不了，只是性价比的trade off。如果引入协处理引擎的综合代价小于获得的加速收益，那就值得考虑。
插句题外话，X86看来异构核心集成趋势已成，集成的众核GPU算是免费午餐。如果能发挥出它在包处理上的加速引擎作用，结果很让人期待。
1k指令的fast path已经足够少了，实际应用里面，但函数入栈出栈等等，就会有很多函数。1k估计是NP之类的编程方式，以linux/bsd，应该比这个多个两三倍。
Panos如果开源了，大家是否感兴趣，我这只是假设，panabit估计不这么想。一个network service platform。
#103, function inlining can be used to get rid of function call overheads.
很多人推崇x86的l4-l7的处理能力，小弟很不以为然，x86的计算能力强就代表l7的处理能力强么..举个例子,在需要查找上万条正则表达式的时候，x86做不来高速..真那样的话路由查找还要tcam干嘛..正则查找比路由查找要复杂哦亲..
搞不懂为什么那么多人这么推崇intel，好像它进入什么领域就能大杀四方..x86用在中低端还可以，千万别把它神化了，软件的筒子们，x86啥都能干就说明它干啥都不能做到极致啊亲，别再纠结这个话题了好么亲..耳朵都快生茧了..
to 99，根本不相干：
需要做硬件收发、进出队列、QOS、报文头处理等等，还有产品化必须的参数判断、可靠性、统计等需求，1k已经是最少的了，如果做保序的话，可能还需要多几百个指令。
你提到的5645是什么架构的x86？ 我的数据是在SNB6c2G基础的结果； 另外我也很关心，你的数据是怎么计算出来的，IPC算多少？
我没说1K很多啊:) 我了解到的数据，这种基于L4流的处理差不多也是1-1.5K
我的意思是相比L2 Forwarding的几十个cycle，L3 Forwarding的200左右cycle，这些上千cycle业务类型的计算需求并不算小，相比之下未必瓶颈就一定在IO
另外to mota：“x86的计算能力强就代表l7的处理能力强么”，赞一个！不过我们也正是在讨论CPU之外引入协处理器的必要性哦亲:)
被楼上秒杀。
大家能谈谈多核场景在应用空间做墙的可能性吗？
to 根本不相干 #109，
至于是否需要协处理器，请参考intel cave creek。
如果ipsec,regex能只用cpu core完成，那intel的架构师只能是脑袋进水，开历史的倒车。
再论intel cave creek chipset，报文流量从cpu导入cave creek，然后再倒腾回来，来回需要浪费多少dram带宽和接口带宽？
还是那句老话，在网络多核处理这个细分领域，intel sandybridge的core的ipc请和xlp832比（所谓的计算能力）。
然后网络接口和报文加速引擎请请和(cavium cn68xx,xlp832）比较。
只谈当前这一代的最高端：sandybridge 8core/xlp832/cavium cn6880.
intel下一代请和这三家的paper chip(rmi xlp9xx, cavium cn7xxxx, fsl t4)比较。
===
阳光下面没有新鲜事！
To: matrix
It is very hard to compare processor performance and it is still the art but science.
What a customer needs is a good and sometimes comparable performance with little efforts. In this sense X86 is better than other multi-core architectures.
For example, since no co-processor can handle regular expressions whose number is more than 10K, using X86 based multi-core to deal with such large number of regular expressions sounds very promising to me.
To #106:
I don’t think it makes sense here. No one claims a SW solution is better than an ASIC. TCAM is an ASIC based solution. Yes, it is faster but costs more and requires more power
Furthermore, when the number of routs is over the capability of a TCAM what do you do? Similarly, is there any HW regular expression engine that can hold 10K rules?
to multithreaded #113
In this sense X86 is better than other multi-core architectures
如果理解architecture为cpu体系结构，x86,vs. MIPS and powerpc，这句话我有条件地同意： 如果您使用的是开源软件(open source application code)，x86有一定优势（其实坦率地说,c code的移植性不用多提）。
如果您本来就是做一个开放平台（比如说server），允许您的客户进行二次开发，这个x86可以说是必须的。
如果把architecture理解成为uArch（微架构），还是那句老话，请比较xlp832和sandybridge的ipc。
频率sandybridge要比xlp832高，这个没有话说，intel的工艺独步天下。但是同事请考虑sandybridge 8core@2.0Ghz TDP 100W的功耗。如果单板能够放得下，这是一种选择。
===
since no co-processor can handle regular expressions whose number is more than 10K
坦率地说，请multithreaded兄更新一下。可以评估rmi xlp316和cavium cn6880的regex引擎。
大路由表的engineering solution是用一种算法ASIC替代TCAM，当没有perfect的可行方案的时候，大多数情况下的解决方案，就是首席一直推崇的trading-off，工作和生活遇到大困难的时候，一定要考虑一下trading-off的方案，不是总要走极端，否则可能害人害己
to 116.理克
Tree-Bit-Map is a good idea.
谢ASR1K指点。你有没有升级过2K？
http://www.dragonhk.com/ 金龙电子是Intel 在中国区的代理,特色是给客户最好的技术支持!
昨天RSA大会Intel演讲中插播了一下天融信用DPDK的案例(or 广告）
透个风，明年Intel的子公司McAfee的安全硬件的个别产品也将投入到基于Sandy Bridge架构，采用Cave Creek和DPDK中。
说一个实测数据：
我最近用i7 2600 + C206 + 82599EB做了万兆捕包和转发开发，不采用裸奔方式，要能有实际应用价值，即采用所谓“零拷贝”方式，就是驱动捕到包后，交由用户空间处理后，再转发或丢弃（目前多数的IDS/IPS都是采用的这种方式）。
具体的方式是采用８线程并行处理数据包，用户空间程序只做很简单处理，实测性能如下：
捕包：64,128,256字节都能达到10G,如果用双网口捕包，基本能到20G
转发：128,256字节都能达到10G(单向)，64字节是80%左右（为什么达不到100%，原因还未查明）。双向256字节可达80%以上。
这个性能还未达到理想数值，但我还未找到瓶颈，如果有哪位在这方面有经验，可以联系我，大家一起研究。
另外，我想研究一下DPDK，不过我现在找不到，哪位有，能否给一份(fxwind@163.com)，多谢！
DPDK的都有NDA。不会随便给你
去下个vtune貌似不要钱，profile一下看看就明了
为啥有人冒用我的名字matrix长篇大论攻击intel,windriver?
该不会是beans大神故意陷害吧，呵呵，千万不要得罪小人啊
楼上说的很对，千万不要得罪小人。。。
近期有机会看了下DPDK的一些东西，个人感觉，从开发难度上说，intel不见的比octeon更容易些，说intel开发比oct简单估计是没用过oct的人说的。试用了下OCT68xx上的HFA，很好用，功能很强大，10k规则 可以达到20G线速，不晓得intel能否达到这个水平，哪位能否说下。
顺便说下，有些时候表面上看起来很简单的东西，用起来反而很复杂，相反表面上看起来很复杂的东西，用起来反而很简单。
我最近也在看DPDK，它有两种工作模式，bare-metal和linuxapp，估计这两种模式的性能要相差不少，我个人认为bare-metal要更好一些。有哪位有这方面的测试数据，能否和大家说一下？如果有时间的话，我可能也会测一下，到时会把数据贴出来。
另外，DPDK也支持intel的82576系列的千兆网卡，实际上，在我122楼帖子所列的测试方法下，用4 port的82576网卡，在组成2组转发线路情况下，能很轻松地达到２路64字节双向100%全转发，CPU的占用也不高。由此可见，如果只是千兆开发的话，DPDK的用处也就不大了，也就不用去学它那套东西了。
千兆开发个啥劲。。。搞几个82599玩玩。。。
linuxapp模式=baremetal+os_overhead。
各人感觉，如果配置得当，os_overhead<1%。完全可以当bearmetal跑。。。
to 128:
请教个细节问题，DPDK的82576/82599驱动是poll模式的（while循环、去掉中断开销），还是NAPI模式的（中断+poll）？
如果是前者，那CPU利用率岂不是一直都是100%?
PS：关于122楼的测试，8个线程是指8个core都参与82599的收/发（8-ring配置），还是指只有1个core进行收/发，由另外7个core进行报文的处理？
前者，一直100%
datapath玩中断开销太大，哪怕就一块82599，20Gbps 10ms进来了也有200Mb，context切不起
to 130:
我的驱动用的是你所说的NAPI模式，在各项测试中，CPU占用都不高，如256字节单向10Ｇ转发，CPU的占用率还不到15%，所以CPU不是瓶颈。
无论捕包还是转发，我这里都是采用的8线程并行方式，即8个core全部参与收/发，对应8个ring。数据包的内容分析通过零拷贝方式交给用户层来处理，8个core也同时做用户空间的数据包内容分析处理，对应8个线程。
由于对数据包内容分析的程序太复杂和庞大(IDS/IPS)，不适宜在内核空间做，只好用零拷贝的方式在用户空间做了。
纯转发，连接表都没有，CPU 15%，256字节，这些数字没有意义，跑个业务看看？8线程并行在用户空间分析包内容，全局数据（如连接表）的互斥访问怎么实现的？7层CPS能到多少？
驱动采用了分流技术，即可按ip或tcp/udp分流，能保证同一个流的数据包一定会被送给同一个用户线程来处理，这样用户线程在处理数据包时就可以很少加锁或根本不用加锁了。
许多数据结构和表，如楼上提到的连接表，在采用分流机制后，完全可以不用加锁就能处理了。
我现在还在优化驱动程序，希望能留更多的CPU资源、内存资源等给用户线程，只有拥有足够的资源，用户程序才能处理得更快。至于有多快，那就要看各家的功力了。
to fxwind
请教个问题：Intel的RSS HASH算法是否能保证同一个连接的双向数据流（源目的地址和端口对换）定向到同一个CORE？如果做不到这一点，如何实现连接表的lockless访问?
没看到intel相关文档对此有说明，还请赐教
to killer:
我明白你的意思，RSS是一个说不清好坏的东西，鸡肋一样，我没有使用它。
我不清楚你的具体需求是什么，看看filter,也许它能帮助你。如果你的需求很复杂，可能就得自己用软件来分流了，很多人就是这么做的。
驱动采用了分流技术，即可按ip或tcp/udp分流，能保证同一个流的数据包一定会被送给同一个用户线程来处理，这样用户线程在处理数据包时就可以很少加锁或根本不用加锁了。
许多数据结构和表，如楼上提到的连接表，在采用分流机制后，完全可以不用加锁就能处理了。
=============
你的流是指连接么？
只有属于同一个连接的报文都被分到一个用户线程了，才有可能做到你说的“完全可以不用加锁”,否则锁是无法避免的。
所以姑且认为你说的流是指连接。
若不采用专有硬件设计，用CPU（driver)将不同的连接分到不同的用户线程（CPU，core),对提高性能帮助不大。因为这意味着要在driver里访问连接表，意味着更多的cache miss。
所以这个功能一般在硬件里做，当然硬件要能识别连接，能访问连接表。
所以很少见到在driver里做分流的（这里的流指连接），特别是对于业务都在应用层处理的构架，这样做是非常不合理的。
你说的分流，准确地说是应该是packet distributing。driver里做packet distributing,对多核系统，则是比价合理的，无论是用CPU，还是利用RSS。
但packet distributing也无法保证“完全可以不用加锁”。
纯X86构架，RSS还是很有用的，因你能做的就是packet distributing。与其让CPU来做，不如交给网卡来做。
我说的流是指连接，双向的。
用软件(driver)来分流是可行的，不用建连接表，也不用加锁，性能也很不错。也许你会怀疑，但至少我遇见过这样的场景(一种多网口捕包应用)，说起来，它就是一种packet distributing，不过它能把连接(双向数据)定向到同一个用户线程而已。
其实，不论采用何种分流方法，都有各自的优缺点，找一个最适合自己应用的，总体性能最高的，那就是最好的。
OK， 流在你的系统里确定就是连接。
想在分流（连接）的时候不访问连接表,而把一个连接两个方向的报文分到一个用户线程，这是不可能的。没有链接表，如何判断不同的报文属于同
一个链接（流）？
若不考虑性能和优化，分流的代码在哪里都可以运行，这个不用怀疑。但在driver里分流对性能没有任何好处，甚至会降低性能，因为就如我刚才说
的，必须在driver里访问连接表。这样做实际上是把业务层对连接表的加锁访问转移到了driver。
即便流已经被分到不同的业务线程，锁也是无法完全避免的。连接表是核心数据结构，但与其相关的代码，只占整个系统很小的比例。
我觉得你说的“分流（连接）而不用访问连接表”的场景，可能是你的一种误解，这种场景应该是不存在的。
另外，能否晒一下你测试的是哪个公司的什么产品？
现在SandyBridge处理layer7业务，10G/核, 至少对大包已经不是问题。
你前面的i7平台，throughout平均到每个核上，数据不算理想，软件还有很大的优化空间。
to gchen:
driver里不建连接表，这是肯定的。至于如何分流，有几种办法，软件分流是一种，它可能做不到通用，但在一些场景，它工作得很好，我认为整体性能比RSS要好，详细我就不说了。如果你还不相信，我只能说，我是做网络数据包内容分析项目的，已经做了几个了，其中零拷贝，分流等（包括千兆和万兆）是我们必须做的，如果你公司有这方面的需求，而又肯出钱，我倒是可以给你做一个看看。
至于性能，7层内容分析大包做到10G真是一点也不稀罕，关键是小包。你可以问问国内做内容处理的一些顶级厂商，小包做到10G的有几？（不要看他们的宣传数据，那是用来忽悠人的）
至于你说的“throughout平均到每个核上，数据不算理想”，我不知你指的是什么。就driver而言，CPU不是瓶颈，一个核也能做到。之所以分流，分核，是为了用户空间程序，那才是CPU消耗大户。网卡是10G的，不会因为平均到每个核上，就变成了11G或12G了。
我的driver是有不少优化空间，我122楼所贴的测试数据，那是刚做出来时的测试数据。经过我这段时间的优化，又有不少提高。现在能做到64字节单向线速转发了，CPU占用也只有20%左右；64字节双向转发差不多能达到22Mpps；单向256字节线速转发CPU也只占10%左右了。我再次强调一下，这些测试数据是在分流，零拷贝到用户空间，并在用户空间做了简单处理（分析包头和计数）的情况下得到的。它不是内核纯转发测试数据，也不是DPDK那种占CPU 100%下的数据，不要和它们比。我这样做driver，是项目的确实需要。
如果你那里有更好的方法，或更快的性能，不妨也贴出来，共同学习一下嘛。
好了，更多的我不再说了，以免担什么嫌疑的。
嗯，fixwnd同学在谈网卡和driver，不是说整机性能。。。。
122楼提到i7 2600（8核)， 20G，我前面说的“throughout 平均到每个核上“，就是指，整机性能简单平均一下，大概2.5G/核（20G/8核）。之所以拿这个不规范的术语来说事，因为主要layer7靠CPU（板子设计固定的前提下）。2.5G/核这个数据对SandyBridge的i7来说，是很低的，所以才会有“软件还有很大的优化空间”一说。这里的软件，当然是指上面的业务层（layer4-layer7)。
其它的，譬如关于不访问连接表而能把一个连接的双向数据流都送到一个线程去处理的说法，都勿需再言，大家说的不是一个东西。
单i7 2600 CPU（8核），保守一点估计的话，大包throughout，60G没有问题(<10G/核）。不错，我指的是layer7。不过我没有详细看i7 2600的参数，可能它和至强还是有很大差别。
用SandyBridge，瓶颈在板子设计和上层软件系统，与网卡driver无关。
更正一下,i7 2600是4核,8线程,这个跟8核还是有很大区别的,60G的估计有待商榷….
to 141
1）对于非nat场景，简单增加一个步骤：5 tuple hash之前先针对ip/port比较下大小，不管src/dst，按大小顺序小的在前大的在后，就能做到双向归一
2）对于nat场景要复杂一些，确实难以简单做到双向hash分流。具体实现考虑如下：流表在driver和app间共享，driver查完流表，结果携带table index，app无需重新查找，这样driver虽然浪费了cycle，但app同样有减少
3）真正复杂的不是core间调度，而是分布式系统，此时板间无共享内存，hash分流是优选(除非前端分流器维护完整的全局流表，但这显然是一个笨拙的方案)。但对于流终结设备(不是那种中间插入侦听类型的)，有一些优化手段：此时一般不用5-tuple做hash，而是3-tuple(只用dst或src)，由于一般至少一侧的port是本机控制面动态分配的，分配时可以让其hash与另一侧保持一致(具体做法是65535个hash预算好，预放入hash partition里)。这样坏处是会损失一些可用port资源，但好处是无流表分流
rss分流的确不是一个商用场景下很有用的特性，限制太大不灵活，实际分流场景非常复杂，也没有什么一招鲜的手段，还是要根据具体业务场景定制实现方案
直接把NAT给忽略了?那当然可以不查连接表就分流。。。
还没接触过连接可以不考虑NAT的环境，所以这个。。大家还是在说不同的东西。。。
不过edge网络设备各种各样，部署环境也不尽相同，不排除有一些设备的连接系统可以完全不考虑NAT。
如果说系统一定要将做NAT的连接和不做NAT的连接区分出来，我只能说这种设计太执着于在driver里分流了。。
分流是个很简单的问题，潜水的大拿们估计懒得看了，俺也不再发有关分流的帖子了。。。 （：
目前DPDK的应用如何？有哪个公司产品化了吗？
我们测试128字节数据包，可以达到线速。