“Intel推出网络芯片 Cave Creek”有65个回复

1. beans 于 2012-02-16 6:18 下午

   这个说的是dpdk配套的那些东西吗？

2. zz 于 2012-02-16 7:36 下午

   设备厂商还敢和intel玩吗？大家肯定不会忘记IXP是怎么玩了大家一票。

3. ABC 于 2012-02-16 7:47 下午

   对没经过IXP忽悠的小厂家可能还会禁不住诱惑的。看Intel的态度吧。

4. kevint 于 2012-02-17 1:26 上午

   主要缺点在于片外。性能成本功耗与cvm，rmi仍旧没法比。打败RMI，CVM有点太小看这几家了。

   当然优点就是x86了

5. multiCore 于 2012-02-17 1:30 上午

   用过IXP1200和2400的人飘过。。。。。。。开发过程那是异常的痛苦啊。。。。。。。。

   ps：顺便求一份北美工作推荐，有5年+的多核处理器和NPU的开发经验，想出去混下

6. multiCore 于 2012-02-17 1:48 上午

   再留个联系方式multicore2000@126.com

7. per 于 2012-02-17 4:51 下午

   看看

8. boox 于 2012-02-17 10:06 下午

   数一数被intel坑过的设备商

9. Panabit 于 2012-02-17 10:17 下午

   这一次和以前不太一样，这次重点在软件，硬件部分基本上都是通用的，所以不存在硬件方面的风险。在通用硬件基础上，软件风险是可控的。

10. julang3 于 2012-02-17 11:48 下午

    期待intel的新动作，从最近的测试来看；intel平台进步相当快；

11. multiCore 于 2012-02-18 12:04 上午

    希望早了点能看到手册，看看和别的厂商的有什么区别，不过一般经验来看，产品的性能总要比产品目标定位打个折的，既然是想取代Cavium和RMI的某些产品，那估计性能肯定不如上述公司的。

12. 狐说 于 2012-02-18 5:37 上午

    对于某些玩开源路由器的厂家来说，是个利好吧？

13. wisco 于 2012-02-18 5:43 上午

    有Cave Greek的芯片架构吗？
    http://www.wiscochina.com
    在这个市场上，cavium/RMI/TILTER已经先入为主了，除非intel能够颠覆这个3家的有点，就如APP手机能够颠覆传统手机厂商NOKIA/MOTO一样。
    不明白INTEL为什么挤破脑袋要进入这个市场，这个市场本身很小。
    为什么不投入更多精力来对付ARM呢？ARM+安卓才是intel的大患呀，手持移动终端，越来越重要了，PC的份额未来是下降趋势，而移动终端是上升趋势的。。。
    不明白。。。。。。。。。。

14. Panabit 于 2012-02-18 6:43 上午

    Intel根本没有投入多少额外的精力进入这个市场，软件是WindRiver或者6Win等提供，硬件是现有的通用硬件架构，只是提供了更好的软件而已。做这个事情，对Intel而言，只是顺一下手而已。

15. 理客 于 2012-02-18 6:50 上午

    intel的能力当然足够做这个市场，但独立产品做这个市场对intel太小，intel试水几次，因为油水太少而放弃，这次应该不会是走回头路。看X86通过通用PC CPU的摩尔定律式性能提升，最终成为服务器市场的主流CPU，使其他服务器专用CPU不得不黯然收场，如果要做中低端通讯市场，也可以用这条路，但intel需要用相对自然的方式把通讯功能带入X86中，如果intel能做到这一点，那么中低端通讯市场的CPU一定是intel的。而对于mobile cpu市场，intel目前好像还没有找到正确的策略，而一直在用atom等延续其X86到PC的方式，其实intel只要做完全的ARM芯片，那么一定能提供最好性价比的产品，但intel作为全球CPU老大霸主，不愿意低下高贵的头，完全follow ARM，在ARM设计公司的余荫下生活，但目前的主流市场已经ARM了，再造一套mobile CPU体系即使是intel，也是很难的，所以intel也难以找到更好的办法。这种尴尬，和nokia不愿意完全follow android是一样的，不同的是nokia的现金流已经被smart phone给刨了，而intel的X86还是真金白银

16. aaa 于 2012-02-18 5:04 下午

    没完全看明白， 数据包是在 Cave Creek 上处理的，还是在Xeon上处理的？

    如果是前者，那么Cave Creek 估计就和原来的IXP的microengine差不多了， 如果是后者Cave Creek 就是些协处理器，桥就是性能的瓶颈了

17. multithreaded 于 2012-02-18 8:29 下午

    看仔细了：“新核心带有加密、压缩和固定字符串和正则表达式模式匹配的硬件加速器”。

    这只是一个协处理器，估计还不如DPDK带来的效益大。

18. multithreaded 于 2012-02-18 8:32 下午

    为什么没有人关心Intel最近宣布的haswell & transaction memory?

19. kevint 于 2012-02-18 9:21 下午

    cavecreek相当于一个集成了加解密引擎和regex的南桥。挂在PCIE下面。与intel的处理器没有直接关系

    这是一个asic，没有可编程能力。所以跟ME没关系

    驱动包可能会放在dpdk里提供，将来当然会进linux。在server市场可能会有用武之地。

20. 根本不相干 于 2012-02-18 9:33 下午

    cave creek是协处理器，就是完成加密，压缩、reg match这些cavium、rmi已经内置的加速功能，弥补x86自身的不足。包转发核心流程仍是cpu配合DPDK完成。这些加速器还是有意义的，和DPDK不矛盾，不过目前看起来性能一般也就10－20G左右。

    所以正如panabit所说，这次不一样，是基于通用x86的平台。要是另一个IXP的话，那根本不用看一定完蛋，但现在就不太好讲了。

    我的疑问是160M pps是几颗CPU搞定的？如果不考虑DDIO，4通道DDR 1600是不够的。但是有DDIO的话，光考虑裸转发，单颗应该有可能达到16×PCIE gen 3的理论带宽。

    multithreaded：那个确实是好东西，不过明年考虑不迟，现在连工程样片都没有可以测的啊：）

21. Panabit 于 2012-02-18 10:20 下午

    关键其实还是在于DPDK将X86的转发性能提上去了，在这个前提下，协处理器是一个补充。没有协处理器，现在很多软件算法也可以在X86强的CPU能力下有不错的表现。如果有协处理器，可以在保持API接口的情况下，使用协处理器代替软件算法。所以一切的核心还是X86核心和DPDK。

22. Panabit 于 2012-02-18 10:26 下午

    还有一点，AES算法已经在CPU中实现了，性能表现还是不错的，AES对于VPN等产品非常重要。

23. dd 于 2012-02-19 4:55 下午

    160Mpps，怎么达到的，拭目以待。

    无线基站有这么大的数据量么？

24. multiCore 于 2012-02-19 6:04 下午

    我觉得Cave Creek+x86的形态有点类似于，之前某些厂商的x86+fpga加速卡的模式，只不过Cave Creek上面完成的功能可能多些。

25. Panabit 于 2012-02-19 6:31 下午

    和X86 + FPGA不一样。FPGA主要是用来提高转发能力的，而Cave Creek只是提供一些加解密、压缩等算法上的功能，转发依旧由X86完成。

26. beans 于 2012-02-19 7:50 下午

    我怎么总觉得dpdk设计的很不好呢，这是我的错觉吗？感觉是对linux kernel了解的不够透彻的人做的设计~~。
    我记得第一次去听dpdk后，和我另一个公司也去听过的老同学分享了一下经验，我们都是觉得这东西是菜鸟设计的，谁用谁吃亏~。
    有做软件的同学有同感的吗？

27. bupabupa 于 2012-02-19 9:03 下午

    去年有幸拜访过intel，也问了他们的老大这货怎么和RMI，CAVIUM去比拼，另外和netronome的3200什么的怎么去评价，人回答的很简单，我们这个就是冲着10G，20G赚钱的市场去的，至于所谓的高端性能，随他们玩去吧：）

28. Panabit 于 2012-02-19 9:05 下午

    DPDK的设计确实不太好，只能说是一个能证明X86转发性能的东西，要想作为平台去使用，还需要大幅度改进。

29. 根本不相干 于 2012-02-19 9:44 下午

    请教Panabit一下，能否粗略说一下DPDK的设计缺陷？

30. Panabit 于 2012-02-19 10:06 下午

    也不能说是缺陷吧，只能说是不完善。DPDK提供了很多基本的机制，但是没有将这些串起来。比如，提供了对网卡收发的高速操作，但是实际中显然需要有一些多CPU同时操作同一个队列所必要的锁保护机制（DPDK的确提供了SPINLOCK，RWLOCK等基本锁）。另外，在packet buffer管理方面也需要继续完善，……

31. beans 于 2012-02-20 1:43 上午

    我觉得真正熟悉linux kernel的人，都不会设计那样的玩艺。只有存在知识盲点的kernel开发人员，才容易做出这样的东西，而且一看就是没考虑实际开发成本，要是个各厂商都投入dpdk的开发，我敢保证，我等做平台开发的程序员，薪酬都能大幅提高，呵呵。
    我听他们讲，就问了一个问题，是不是这东西是为了版权才设计成这样的…..

32. aaa 于 2012-02-20 1:53 上午

    ok, 如果是协处理器，就是说，人家XLP，Cavium集成在一个芯片的东西， Intel拆成2个片子，如果价格合理，也不是不行。

    160Mpps，应该不算什么难题吧，如果按一个packet 100instructions 这么算，16 core 1.2GHz 就差不多了，何况Intel 肯定能比1.2GHz 高不少。

    传说中的DPDK，到底怎么样？ 有商用的案例么？ 看6wind的指标可挺好， Windriver应该只能更好吧？ 问题是实际上客户用的如何，实验室的数据，水分太多

33. aaa 于 2012-02-20 3:39 上午

    查了查6wind的网站，On a dual-Intel® Xeon® processor E5645 platform with a clock speed of 3.33GHz, running the Intel DPDK, 6WINDGate delivers over 16 million packets per second, per core of IP forwarding performance, thereby forwarding 10Gbps of network traffic in each core (64-byte packets). 而且这个性能是随着core的数目线性增长， 因此10个Core就是 160Mpps了，当然每个socket最多8个core， 用QPI连两个socket估计有点损失吧（到底是UNMA，但是理论上也应该没啥大损失， packet之间的数据相关性不大），16个core肯定也可以了

34. frmfra 于 2012-02-20 5:11 下午

    dpdk其中有些开发人员是搞了二十年的unix/linux kernel、networking的专家级工程师，有知名开源软件的创始人，有RFC的相关协议的编写者。建议大家虚心仔细研究下dpdk。

35. dd 于 2012-02-20 5:38 下午

    Panabit说的很有道理，现在DPDK依靠多核、多队列来避免互斥。

    锁的代价非常高昂，对性能一定损失很大。e1000e网卡驱动发包时使用的writel和mmiowb来保证多CPU对同一队列操作的互斥。
    writel(i, tx_ring->tail);
    /*
    * we need this if more than one processor can write to our tail
    * at a time, it synchronizes IO on IA64/Altix systems
    */
    mmiowb();
    不知道为什么DPDK没有使用这种机制？

    Panabit帮给指点一下。

36. beans 于 2012-02-20 6:49 下午

    DPDK的现在就是6wind风河在用，不过他们也不是用来出产品，就是出平台的，但是大点的公司都会自己开发平台，就是x86的多核，也没什么难度，干吗要花钱去买6wind和风河的呢。Intel要么就自己做好点，可以让大家直接用，干吗还要有人中间扒皮呢？

37. julang3 于 2012-02-20 9:15 下午

    比较好的设计是同时提供加锁版和无锁版接口；
    有的应用可能刚好一个cpu core一个queue 的操作方式；如果使用加锁的接口，可能会有性能损失

38. 根本不相干 于 2012-02-20 9:41 下午

    谢panabit!

    160M pps如果用多个CPU去堆，这种算法毫无意义，单CPU性能才是衡量intel能力的硬指标。如果真正达到，毫无疑问是用了DDIO等cache直通技术，绕开了DRAM读写。100G流量如果缓存1ms，也就是12.5M，放在LLC应该没有问题。

39. Panabit 于 2012-02-21 2:13 上午

    回34楼：我说的锁不是指你说的writel之类，你提供的这些应该是和ATOMIC原子操作以及内存保序有关。X86缺省就是strict order的，所以不需要再封装一个你说的writel之类。DPDK为什么不用锁，我并不清楚。我只是觉得他们主要是以提供砖瓦为基础吧，如何通过这些砖瓦造房子，Intel可能认为是用户自己的事情。

40. aaa 于 2012-02-21 7:13 上午

    to 37座， 如果单个Core 就能160Mpps， 有点夸张。 再说， 人家Intel现在也是一个芯片里面2~6个核， 没理由只说单核性能。

41. Panabit 于 2012-02-21 9:21 上午

    160Mpps估计是两个双路8核的数据吧，也就是说平均每隔核大概是10Mpps。

42. 根本不相干 于 2012-02-21 10:02 上午

    那这个数据没什么啊，相比之前的没有突破，不知道为什么发布一把。

    我还以为有DDIO的缘故能直写cache，可以把单CPU的pps上一个台阶

43. dd 于 2012-02-21 5:50 下午

    to Panabit,我有一个问题很疑惑。

    当CPU核多，网卡发送队列少时，必然出现多CPU同时操作一个发送队列的情况。
    Linux内核使用HARD_TX_LOCK来避免互斥，这个锁应该比较耗性能，有什么好的办法避免么？

44. kevint 于 2012-02-21 6:14 下午

    要么你多加一级Q。。。
    另外，印象中82599 有128个tx queue。我见过最烂的卡也有8个tx queue。。。

45. kernelchina 于 2012-02-21 6:50 下午

    发送可以用一个cpu专门去管发送，不过锁是没法避免的，share resource。

46. aaabbb 于 2012-02-21 8:35 下午

    接收通过五元组hash到不同的cpu上，发送通过往不同的队列发送。

47. 根本不相干 于 2012-02-21 9:30 下午

    5-tuple分流是最简单的处理，但只能用于简单网络，对于隧道接口就无法负载均衡了。

    因此，要看具体处理的业务。比如enterprise edge，由于业务量不大且业务复杂，可以用一个核专门来做分发（分发规则会非常复杂，有可能需要看到内层隧道ID比如gre key, ipsec sa，但分发处理会非常简单，且基本能命中cache访存很少）。做完后可以放不同队列，应该不会存在锁的问题

48. stupid 于 2012-02-24 7:14 上午

    全球嵌入式及移动应用软件领导厂商风河（Wind River），今日宣布已和Sensory Networks这家业界领先的模式匹配以及深层封包检测（DPI，Deep Packet Inspection）软件加速技术供应商携手合作。双方将在本届MWC世界移动通信大会中共同展示DPI网络安全解决方案。这次展示将让大家清楚看到，一套内建DPI软件的操作系统将如何提供媲美有线网络传输速度的内容检测功能。

    不断涌入市场的各类新颖移动设备，加上如LTE（Long-Term Evolution）这类4G网络技术的持续演进，均使得网络上的信息流量暴增，不过，足以威胁信息安全的网络攻击比例却也一路攀升，两相作用下，使得管理上对每一个信息数据包进行检测的必要性大增。有鉴于此，网络设备也相应出现一股革新需求，不但必须提升封包传输量性能，还要能更聪明地处理信息，并具备更佳的安全防护能力。

    DPI功能是网络安全应用中不可或缺的一环，唯有通过这项功能，才能逐一检测信息流及封包以便找出恶意内容。随着恶意软件及其威胁的手法日益精巧细腻，网络设备必须能对传入的信息提供更为详尽的检测，但是却不能因此牺牲丝毫性能。以软件为基础的DPI机制可以提供一套兼具成本效益和扩充弹性的解决方案，好随着不断变迁的网络安全市场需求灵活调整。不同于传统的防火墙及入侵侦测系统仅会检测封包的标头，DPI功能可以落实对每一个封包的标头和Payload的检测，为强大的网络安全应用奠定坚实的基础。

    在本届MWC世界移动通信大会中展出的DPI解决方案，包括了整合Sensory Networks HyperScan技术的电信等级Wind River Linux操作系统，后者并已针对多核硬件与英特尔DPDK开发套件（Intel® Data Plane Development Kit）最佳化；软件及处理器等硬件部分，则已整合至一套艾默生网络能源公司的商规Multi-Gigabit平台上。HyperScan技术与Wind River Linux的搭配提供了一个极佳范例，两者所构成的整合性软件解决方案，使网络安全设备可以在符合经济效益的前提下，以媲美有线网络传输的速度对资料内容进行筛检。此外，DPI软件也可以提升如入侵预防、antiX、防火墙、内容过滤、应用识别、整合式威胁管控等机制的封包处理效能。

    风河网络及电信部门副总裁暨总经理Mike Langlois表示：“移动设备以及其他各类连网设备快速增加，使得网络上产出的信息封包类型越来越多，数量也越来越庞大，必须对这些封包予以妥善排序并加速处理，才能为客户提供品质一流及符合优良用户体验的服务内容。不过，随着网络信息流量快速成长，安全攻击事件层出不穷，恶意软件的数量也持续攀升。本次我们与Sensory Networks合作推出的DPI解决方案，向各界展示了如何回应并满足来自网络安全应用方面的关键需求，包括进行更多高复杂度的网络内容筛检、以更快的速度处理更为庞大的信息流量，以及如何化解造成网络瓶颈的风险。”

    Sensory Networks执行长Sab Gosal指出：“对网络设备制造商来说，如何为产品加入更好的安全防护机制以及智能功能，但又同时维持高品质网络性能，是相当重要的一件工作。凭借HyperScan DPI软件技术，网络及安全防护设备供应商将可显著提升旗下产品的内容筛检作业性能，并让产品变得更聪明、更灵活。而我们的HyperScan技术与针对市场领先的多核处理器架构优化的Wind River Linux平台之结合，更充分展现了一套稳固的电信等级作业系统，将可如何提供媲美有线网络传输速度的内容检测与安全防护解决方案。”

    Sensory Networks HyperScan是一套高速模式匹配软件，主要用于整合至网络及安全防护产品中。这套软件可以支援类型广泛的应用，包括IPS/IDS、防火墙、DPI、内容过滤等，此软件引擎更可在扫描由成千上万个特征档所组成的庞大资料库时，提供优化效能。HyperScan的设计可同时因应单核心和多核心处理器硬件架构，自1 Gbps以下乃至160 Gbps的运算速度均可配合，视实际使用的处理器核心多寡而异。

    此外，HyperScan可以简化产品的工程暨设计流程，设备制造商仅需针对单一系统进行一次整合作业，即可将成果套用至整个产品线，甚至可涵盖未来升级后的产品，使其可顺利向下相容。

49. 理客 于 2012-02-24 12:49 下午

    对于日益成为整个社会基础架构的IP网络，流量越来越复杂，DPI十分有意义。但DPI如何用在网络上？作为承载网，不可能把DPI布得到处都是，因为承载网的目的是提供低成本、可靠好管理的带宽，目前网络级的DPI架构还基本没人考虑，DPI的目标是协议报文和数据报文的报文头，是否可以通过云计算来实现DPI？网络传输设备把协议报文和数据报文头发给云计算来做进一步识别，这正做有三个问题：
    1、带宽占用率是否feasible？
    2、如何识别是协议报文？
    3、如此带来的滞后是否feasible？

50. ABC 于 2012-02-25 12:09 上午

    对DPI部署在网络中一直感觉怪怪的，首先性能上就存在问题。目前网络设备大多检测不了这么深的报文结构，否则就会造成性能下降。
    不知道48楼说的风河内嵌DPI的平台能产生什么轰动效应。
    如果DPI真的在网络设备上大规模铺开？
    楼下请继续发散吧……

51. aaa 于 2012-02-26 5:32 上午

    承载网上的芯片，好像不允许有DPI功能，否则有些国家，例如美国，是不允许进入的。

    —这是我听说的。

    应该是企业网，接入侧用的把

52. flead 于 2012-03-02 5:10 上午

    DPI类似功能在网络上发散在天朝是有可能的。
    现在某些市移动已经部署&测试过类似功能了。

53. flead 于 2012-03-02 5:13 上午

    to：47楼
    是否可考虑协议剥离？
    处理后恢复协议头。

54. TX 于 2012-03-02 3:04 下午

    不错，看来INTEL持续增强网络处理性能，对中小厂商是利好

55. aaa 于 2012-03-05 2:42 上午

    今天看到 http://www.mpronline.com/index.php 上说， 这个cave creek 是10Gpbs IPsec performance ， 这个和160Mpps也落差太大了点。。。

    而且这种实验室数据，真用起来，打个50%的折扣可能都算少的了。 。。。

56. hid 于 2012-03-08 6:32 下午

    Intel发业界首个整合版万兆网络芯片

    Intel正式发布了型号为X540的以太网控制器。作为业界首个全整合方案万兆网络芯片，X540的单芯方案可进一步节省空间和能耗，可适用于板载及独立网卡。

    此外，Intel X540还可向下兼容10M/100M/1000M网络。与其他Intel万兆网络产品相同，Intel X540提供高级I/O虚拟化，支持iSCSI（Internet Small Computer System Interface）和FCoE（Fibre Channel over Ethernet）功能；和前日发布的Sandy Bridge-EP架构Xeon E5系列产品是最佳搭档，可从E5平台的强大I/O中获益。

    目前采用Intel X540控制器的独立网卡X540-AT2官方推荐售价为124.34美元，采用PCIe 2.1界面。

    板载X540 10GbE网络解决方案

    采用X540的独立网卡

    不知道Intel X540提供的高级I/O虚拟化的功能会不会对虚机有优化？

57. Ax 于 2012-04-26 8:05 下午

    我潜水好久了，我看到大家都在讨论intel的DPDK，我没看到过东西，不知道Panabit 能不能把它和netmap, ntzc等的实现比较一下，谢谢！

58. EZ微码 于 2012-05-01 2:44 上午

    160MPPS的处理内核但是只有4个千M的MAC，做转发packet要咋咋送到Cave Creek 里面去呢？价格便宜编程简单的话做个控制cpu用？这个片子的定位很奇怪啊。

59. kevint 于 2012-05-01 10:27 上午

    via QPI

60. multithread 于 2012-05-01 3:58 下午

    I think it is through PCIe

61. kevint 于 2012-05-02 12:07 下午

    stupid typo
    via DMI and PCIE

62. 曲径通幽 于 2012-05-19 5:13 下午

    看了通篇，我发现是不是DPI有得做？

63. 大兵小将 于 2012-06-01 11:35 上午

    各位，硬件商是要制造网安行业的”联科发”吗？ 有没有可能3、5 年之后，网安公司只要自己替换一下LOGO 就可以发布自己的产品了？

64. interbeing 于 2013-07-09 7:08 下午

    这个国内已经有产品基于这个出来了。
    http://www.cnw.com.cn/news-china/htm2013/20130627_273826.shtml

    由于NFV,Cloud的推动，这个及DPDK 目前很热门。

65. stupid 于 2013-07-14 6:29 下午

    谢谢分享资讯。