“硬件网络加速–杭州攀克网络（PakFlow）”有75个回复

1. 陈怀临 于 2011-03-19 3:59 下午

   我与这家公司的老总是多年的弟兄。在北京的同学们，如果有心加盟。请把RESUME给我。。。该老总人厚道，技术精湛。。。薪水给的非常丰厚。

2. Xin Qian 于 2011-03-19 7:35 下午

   不是这行的专家，但是想问问在现在CPU这么便宜的年代，网络接口这个部分用NP来分流，上面用CPU farm来处理数据包完成路由，分类的运算，不用硬件来完成路由和数据包的区分。这种架构在上面这个产品的市场可行吗？

   NP和CPU之间的连接确实是个问题，怎么做那个bus确实很是问题，上次有个帖子：“华为发布业界首款Terabit处理能力防火墙”我就很好奇，它们怎么做的板卡间的互联。

3. fastpath 于 2011-03-19 7:42 下午

   现在也有类似概念芯片，CPU+fast path engines，比如Axxia。关键就是看谁的性价比更高。

4. sniper 于 2011-03-19 7:51 下午

   1，这种方案的最大带宽是多少（以该公司能跑到的最高频率的asic为例）
   2，能保证flow里第一个通过cpu转发的pkt与pakflow转发的pkt的顺序么

5. kk 于 2011-03-20 12:47 上午

   这个思路，某个公司吹嘘的“目前全球处理性能最高的分布式防火墙”就是这样的吧。只不过CPU是XXX???，类似PakFlow是？个FPGA吧。杭州，呵呵！

6. 受刺激了 于 2011-03-20 6:54 上午

   CR兄的公司？？？

7. Qi 于 2011-03-20 7:05 上午

   方案可行，2*10Ge在PCIe 3.0下使用Sandy Bridge8核能够处理。技术细节有很多，一句两句说不完。中心还是Cache那点事，做好并不容易。

   随便问一句，这个公司不是H3C控股的那家吗？

8. Peter 于 2011-03-20 6:35 下午

   为啥不用多核处理器来配合sandbridge做前端分流处理呢，比FPGA容易设计，价格也不一定贵，当然多核处理器上面也可以run zero overhead linux。

9. zeroflag 于 2011-03-20 6:39 下午

   这种基于x86 + PCI-E + ASIC/FPGA的方案，在中低端市场，例如Software Based Router， Software Based Firewall/UTM方面，是非常有竞争力的。

   ——已经引入了FPGA，为什么要定位在中低端？现在用X86做到1～2G都是松松的，干嘛还要再引入一个FPGA？还是说我们对中低端的理解不一致，您是把10G左右的性能定位在中低端？

10. picktracy 于 2011-03-20 6:55 下午

    瞅着这么眼熟，不只我，相信很多人都应该有过类似的想法。
    问个问题：如果插多块PakFlow，这几块PakFlow间如何通信？即跨卡流量如何处理？是否需要CPU参与？

    PS:Tilera已有PCIE卡方案，当年试图用它的卡在x86上构造一个类似SRX5800的山寨系统，未遂。。。

11. softarts 于 2011-03-20 7:04 下午

    为什么英文主页是linked到sangfor?

12. babyface 于 2011-03-20 9:31 下午

    这样的加速卡芯片市面上挺多的，不知道这个高不成低不就的10G带宽在什么场合下会被应用，另外在修改包的功能上貌似只能做简单的nat,这样能满足安全厂商的要求么

13. dushuwa 于 2011-03-20 10:46 下午

    为什么英文主页是linked到sangfor?

    哪里发现的？

14. xiudong 于 2011-03-20 11:08 下午

    …网页模板等等和sangfor的网站一模一样，我表示很惊讶-_-!，太像了，整个页面的颜色风格都一样.www.sangfor.com.cn

15. 卖龙 于 2011-03-21 12:11 上午

    很感兴趣这家公司，可以入股么？

    当前未加速的10GE卡，会消耗CPU性能，加速以后，希望可以减轻CPU20%负担，或者说提升CPU20%以上的处理能力。

    卡的性能俺倒觉得不是关键，倒是交换机的性能和价格成了普及的障碍。

    早期应用会觉得1GE太慢，10GE太快，多数需要2G~4G的时候，如果10GE卡性能差点，交换机的性能也差点，都只达到4G左右，而价格接近GE，俺觉得这个产业就给推进了。

    具备10GE兼容接口，性能和价格都相对低一些的产品，台湾很擅长做，如果台湾发布了这样的产品，高性能10GE就鸭梨大了。

16. pk 于 2011-03-21 12:33 上午

    PakFlow的加速卡可以实现4G~10G的小包线速，目前的X86还不太容易达到这个速度。在中低端上，
    公司能够提供较低成本的解决方案，取代目前广泛使用的网卡芯片，既能实现网卡的功能，还可以实现4G小包线速转发。

17. Panabit 于 2011-03-21 2:09 上午

    根据我们最新评估的结果，Sandy Bridge轻轻松松小包10G以上。与其在性能上做文章，还不如多在功能上做一些文章。Sandy Bridge做到小包10G+，用于20G（两个万M SFP+接口）环境，成本在15K RMB左右。你们这个阶次的成本大概多少？

18. 加菲猫 于 2011-03-21 2:31 上午

    比较关心他和x86之间的pcie带宽能达到多少?

    小包带宽(64byte) & 大包带宽(>512byte)?
    是否需要小包聚合, 还是直接DMA?

19. dotslash 于 2011-03-21 3:04 上午

    很神奇啊，怎么和恒扬科技NSA卡08年发布的白皮书中有大段大段的文字描述完全相同，当然恒扬的白皮书中还有更详细完整的处理流程描述以及开放的驱动代码、内核补丁和示例程序等等；而也正是因为同比性能下从1G到10G的网关、路由设备用FPGA实现的量产BOM成本和研发工程成本都比Cavium多核乃至X86要差很多，所以，恒扬老的加速卡产品已在被多核整机逐步替代。

    顺便说，做router/security gateway的话，用多核处理万兆小包线速的整机成本，比处理4G小包FPGA加速卡成本还要低，而用多核处理千兆小包线速的整机成本，也就是处理千兆线速低端FPGA加速卡的几分之一而已。

20. babyface 于 2011-03-21 3:21 上午

    to Panabit,请教下如果用sandy bridge来做到10G以上的话都包含什么操作，如果要做nat或者vlan查找替换等等的操作性能会下降的厉害么

21. 老韩 于 2011-03-21 3:36 上午

    @8，我倒是觉得这个方案最好的一点是给设备制造商提供了turnkey交付的能力，可以在投入有限人力物力的情况下快速出产品。

22. brave 于 2011-03-21 3:38 上午

    x86 + PCI-E + ASIC/FPGA的网络加速卡，恒扬科技早在2008年3月就发布了：http://www.semptian.com/news/20080305.html

23. 老韩 于 2011-03-21 4:10 上午

    PakFlow方案的历史恐怕更悠久吧，其在国内外都是经过大量应用考验的。再说还有比其更根正苗红的么？

24. Panabit 于 2011-03-21 5:20 上午

    回20楼：如果做的操作相当于防火墙的FAST PATH，外加一些统计信息，那么结果大概是纯转发的60~70%。这个比例还是可以的。现在很期待正式的Sandy Bridge产品，看看纯转发能否到40Mpps。如果能做到，那这个软件万M方案还是很有竞争力的。

25. 阿土仔 于 2011-03-21 5:52 上午

    To Panabit:测试场景如何？是随机打多条流的吗？DDR3的访问带宽够吗？我指得是Trc

26. Panabit 于 2011-03-21 6:08 上午

    固定的几百条流。我没有太关注TRC。

27. liumang 于 2011-03-21 7:48 上午

    PakFlow的方案有拾人牙慧之嫌，X86+FPGA这种架构早在几年前就有人在做了，现在这种方案已经过时了。目前做安全网关产品的话，用Cavium多核平台，是一种趋势

28. 阿土仔 于 2011-03-21 7:49 上午

    几百条流是不是cache住了很多？如果打1M条流的性能如何？而硬件加速的情况下打多少条流性能都不下降

29. Nicky 于 2011-03-21 8:18 上午

    这种方式最大的好处不一定是成本，灵活性方面优势可能更明显。当需要添加新业务时，仅仅需要升级控制面软件，无需改动硬件。相比之下，自己去做多核NP的转发逻辑，可用开发人力资源相对稀缺的，当然多核NP也可以做成流表转发的固定逻辑，然后将来功能增加只涉及上面的x86软件，尽量再少动微码。

    就市场定位而言，企业边缘更重视面向业务的控制，因此功能上快速响应和更新，比单纯包转发性能更重要。目前应该没多少家企业边缘能超过10G的流量，除了那些大型ICP外。如果10G算中低端的话，那这个中低端至少有80%的市场覆盖面。

    但是，以上分析是建立在一个前提下的：即硬件流处理能够涵盖主要网络包处理的基本转发逻辑，而基本的5元组远远不够。其实openflow也是想完成类似的事情(先抛开其控制面用SSL拉远这一争议巨大的组网方式不谈)：一个符合标准的openflow switch硬件无需改动，就可以通过软件设置完成不同的网络功能。从1.0的单表11元组，到1.1的多表15元组，可以看出他们在应对网络包处理各种复杂场景上做的努力和进步。即使如此，1.1仍然没有native地支持各种隧道接口，而是通过virtual port方式把它扔给了flow switch之外的硬件逻辑(我觉得主要原因是穷举各种封包格式的数量太多了，很难去挨个定义push和pop操作)。

    流表操作如果不能涵盖所有转发逻辑，其吸引力就打折扣了。比如攀克的VPN性能只有500M(10G接口规格的也一样)，我猜测是用x86软件做的。如果不用软件就只能再单独增加包处理逻辑，硬件需要修改。

    我个人其实非常看好流表在边缘设备上的应用，可惜目前市面上出现的解决方案都不能满足功能要求。即使是象Netronome这样用多核NP做的流处理器，对流表的match字段连openflow 1.0的规范11元组都没达到(当然它可以微码编程补充实现，但我宁可留给厂家自己去搞定，毕竟这部分没有个性化，不增值)

30. Will Chie 于 2011-03-21 11:11 上午

    一：首先要明确这个芯片到底是给什么设备用的，根据我的业内经验，这个芯片不是给路由交换之类的设备用的，事实上，主要就是给防火墙、UTM等安全设备用的，这类设备最大的特点就是存在fast path和slow path。

    二：它的复杂度和多核的比较要看架构，例如：x86两个核，一个用于slow path，一个用于fast path，那么跟定要比fpga简单，虽然fpga把fast path实现到了硬件中，但是对于session的下发，各种协议状态的变迁的同步，还有统计信息的同步收集等问题，做过的都知道，linux的arp状态很复杂的说，这些并不容易，当然换来的肯定也是性能上的提升。顺便说一嘴，其实fpga的session可能不仅是五元组，有些实现还需要MAC，当然这种更快些。当然绝大多数多核不是这样的，但复杂度也并不主要在fast path上，如果多核的fast path需要改，那么肯定是更复杂的业务，要么fpga实现不了，要么fpga都需要改硬件设计了，综上所述，fpga并不能简化设计，而是提高了性能，但据说某国内知名厂商的测试结论是：当前多核NP用的好，硬件加速意义已经不大了。

    三：fpga卡的性能的确不是x86单纯转发能比的，因为它省出CPU处理更复杂的业务逻辑（slow path），而且如果是带接口的，fast path可能不经过系统总线，对x86处理slow path的影响较小。

    四：fpga卡的bus和机框式的架构的bus不是一码事情，前者基本用的就是PCI-E，后者可以上网搜一下机框式的交换机的背板总线，一样的。

    五：关于fpga的架构，首席最有发言权了，netscreen是最早把asic用于防火墙的，而fpga是由此衍生而来。软件架构基本一致。

    六：openflow的事情将来可能需要交给交换芯片去做。

31. Will Chie 于 2011-03-21 11:13 上午

    上面写的有问题，不是有些fpga的实现的session需要MAC，而是都要有。

32. hanx 于 2011-03-21 11:24 上午

    唉，大家别藏着掖着呀，搞技术的要杜绝信息不对称呀。

    netfpga.org估计不少人都知道吧，硬件开源，软件开源，就差台湾深圳制造厂批量生产了，再出来几个解决方案供应商，各山寨公司就都能做低成本高性能小包防火墙了。

    顺便提一下atom e600系列集成的fpga也是6万个逻辑单元，上次弯曲这里有个人说他们这种板子可以做到800块成本带4个网口还带交换芯片，如果是真的，是不是意味着cavium在低端有可能被x86扳回来？

    攀克的背景是不是原来intel ixp team出来的那家？请教一下，如果上面提到的开源方案山寨化了，攀克会如何保证竞争优势呢，应该不会是转向更高端市场吧。

33. george 于 2011-03-21 6:48 下午

    to 23#，根正苗红，精准的描述。这种方案确实过时了，唯一的优势就是低成本、集成到产品中的技术难度比较低。
    以x86的势头，三年以后这种方案就可以进博物馆了。

34. Will Chie 于 2011-03-21 6:54 下午

    “上面写的有问题，不是有些fpga的实现的session需要MAC，而是都要有。”

    晕，上面本来有条我发的评论的，发送失败了？

35. Will Chie 于 2011-03-21 7:00 下午

    本来这个是30楼那个评论之前发的：
    一：首先要明确这个芯片到底是给什么设备用的，根据我的业内经验，这个芯片不是给路由交换之类的设备用的，事实上，主要就是给防火墙、UTM等安全设备用的，这类设备最大的特点就是存在fast path和slow path。
    二：它的复杂度和多核的比较要看架构，例如：x86两个核，一个用于slow path，一个用于fast path，那么跟定要比fpga简单，虽然fpga把fast path实现到了硬件中，但是对于session的下发，各种协议状态的变迁的同步，还有统计信息的同步收集等问题，做过的都知道，linux的arp状态很复杂的说，这些并不容易，当然换来的肯定也是性能上的提升。顺便说一嘴，其实fpga的session可能不仅是五元组，有些实现还需要MAC，当然这种更快些。当然绝大多数多核不是这样的，但复杂度也并不主要在fast path上，如果多核的fast path需要改，那么肯定是更复杂的业务，要么fpga实现不了，要么fpga都需要改硬件设计了，综上所述，fpga并不能简化设计，而是提高了性能，但据说某国内知名厂商的测试结论是：当前多核NP用的好，硬件加速意义已经不大了。
    三：fpga卡的性能的确不是x86单纯转发能比的，因为它省出CPU处理更复杂的业务逻辑（slow path），而且如果是带接口的，fast path可能不经过系统总线，对x86处理slow path的影响较小。
    四：fpga卡的bus和机框式的架构的bus不是一码事情，前者基本用的就是PCI-E，后者可以上网搜一下机框式的交换机的背板总线，一样的。
    五：关于fpga的架构，netscreen是最早把asic用于防火墙的，而fpga是由此衍生而来。软件架构基本一致。
    六：openflow的事情将来可能需要交给交换芯片去做。

36. vesus 于 2011-03-21 7:27 下午

    这玩意支持IPv6吗？支持打VLAN Tag的traffic吗？还是不care？

37. Will Chie 于 2011-03-21 7:36 下午

    IPv6的路由是上层业务实现的，它要支持的无非就是v6地址的match。上层业务已经将3层地址转换为二层地址放入session中下发给fpga了。

38. Will Chie 于 2011-03-21 7:37 下午

    一：首先要明确这个芯片到底是给什么设备用的，这个芯片应该不是给路由交换之类的设备用的，事实上，主要就是给防火墙、UTM等安全设备用的，这类设备最大的特点就是存在fast path和slow path。
    二：它的复杂度和多核的比较要看架构，例如：x86两个核，一个用于slow path，一个用于fast path，那么跟定要比fpga简单，虽然fpga把fast path实现到了硬件中，但是对于session的下发，各种协议状态的变迁的同步，还有统计信息的同步收集等问题，做过的都知道，linux的arp状态很复杂的说，这些并不容易，当然换来的肯定也是性能上的提升。顺便说一嘴，其实fpga的session可能不仅是五元组，有些实现还需要MAC，当然这种更快些。当然绝大多数多核不是这样的，但复杂度也并不主要在fast path上，如果多核的fast path需要改，那么肯定是更复杂的业务，要么fpga实现不了，要么fpga都需要改硬件设计了，综上所述，fpga并不能简化设计，而是提高了性能，但据说某国内知名厂商的测试结论是：当前多核NP用的好，硬件加速意义已经不大了。

39. Will Chie 于 2011-03-21 7:38 下午

    三：fpga卡的性能的确不是x86单纯转发能比的，因为它省出CPU处理更复杂的业务逻辑（slow path），而且如果是带接口的，fast path可能不经过系统总线，对x86处理slow path的影响较小。
    四：fpga卡的bus和机框式的架构的bus不是一码事情，前者基本用的就是PCI-E，后者可以上网搜一下机框式的交换机的背板总线，一样的。
    五：关于fpga的架构，netscreen是最早把asic用于防火墙的，而fpga是由此衍生而来。软件架构基本一致。
    六：openflow的事情将来可能需要交给交换芯片去做。

40. Will Chie 于 2011-03-21 7:38 下午

    三：fpga卡的性能的确不是x86单纯转发能比的，因为它省出CPU处理更复杂的业务逻辑（slow path），而且如果是带接口的，fast path可能不经过系统总线，对x86处理slow path的影响较小。
    四：fpga卡的bus和机框式的架构的bus不是一码事情，前者基本用的就是PCI-E，后者可以上网搜一下机框式的交换机的背板总线，一样的。
    五：关于fpga的架构，ns是最早把asic用于防火墙的，而fpga是由此衍生而来。软件架构基本一致。
    六：openflow的事情将来可能需要交给交换芯片去做。

41. caijimin 于 2011-03-21 7:40 下午

    我们曾经测试过类似的产品，除了简单的5元组session管理外，也可针对payload做编程处理，比如看到http到facebook的就阻断;) （据厂家声称某国某墙也使用了他们的产品）。测试了一段时间，感觉对性能的提升不够明显，另外就是要双方协调做不少事情才能用好这张卡，价格又居高不下。

    我对恒扬科技的产品也很感兴趣，有没有人知道哪个厂家在用？效果如何？

42. 泛腾电子-徐鹤军 于 2011-03-21 9:06 下午

    现在还有人在讨论FPGA处理网络包，真是太out了。

43. hanx 于 2011-03-21 9:54 下午

    to 42徐总，俺不太认同您的意见

    怎么out了,fpga今明两年就能过渡到2xnm工艺，如果软件层面开源后足够丰富，开发难度大大降低。

    说fpga不如np的无非是np的软件相对好做好优化吧，做fpga的人难找，又懂算法又懂fpga，并能有效map问题的人就更难找了。

    超便宜的多核arm+fpga，x86+fpga，能不能大规模应用，关键还是软件生态能不能起来，比如netfpga现在都有centos的标准发行版了，入门十分easy，花几千块钱买个样卡，就能启动原型，主要还是缺人缺成熟应用的问题。

    可这几年a,x公司都在大搞校园活动，这一批人成长起来后很有可能就倾向这个方案，另外intel自身也在投入这个领域。

    所以我反而觉得专用cpu方向以后会受到挤压的，毕竟一家公司很难撑起一个产业生态圈。

44. z3326 于 2011-03-21 10:00 下午

    to Hanx 你也徐总啊

45. kevin 于 2011-03-21 10:39 下午

    fpga灵活不如软件，效率不如硬件。做做辅助还行。

46. hanx 于 2011-03-21 11:43 下午

    to z3326,啥意思呀

47. 阿土仔 于 2011-03-22 2:03 上午

    百花齐放，差异竞争。都用同一架构，性能上不会有本质的区别，到头来就是拼成本。

48. 泛腾电子-徐鹤军 于 2011-03-22 2:51 上午

    To hanx,

    FPGA 的瓶颈你自己都已经说了，这些瓶颈不是做做校园普及就可以解决的。

49. 剃刀 于 2011-03-23 1:41 上午

    大家的眼光应该放开一点,不要光盯着多核网络处理器，fpga的人员缺，精熟网络处理器的人不缺吗？
    我觉得这个方案的好处有一点，如果fpga设计的架构比较优化，扩展性好一点。随着fpga的不断进步，这类产品会有很长的生命期的。而且很灵活，可以用更高端的fpga向高端发展，也可以用低端的fpga向下延伸。好就好在fpga也是个通用的片片。也在追着摩尔定律走。是不是intel也看到这一点了。

50. Multithreaded 于 2011-03-23 11:10 上午

    I wonder whether Pakflow can replace the NIC. For example, the user maunal for Intel 82599 has 600+ pages

    Some features are easier for Pakflow to support like vlan filtering. But the following features are very important for supporting multi-core programming:

    1. DCA
    2. MSI-X
    3. RSS

    If Pakflow doesn’t support these features, it would be severely limited in multi-core applications.

51. Multithreaded 于 2011-03-23 11:22 上午

    >五元组连接首包采用传统的CPU处理方式, 在CPU获得必要的路由信息, TCP/UDP等协议状态跟踪信息等内容后, 把针对该流的安全策略（允许通过/拒绝/统计/镜像/交CPU处理等）, 路由信息（出接口/下一跳）和处理策略（nat/路由/桥接/qos）等内容下发到加速卡中，形成加速卡可以直接处理的连接转发表项。

    It seems to me that this design is inviting the DDOS SYN attack like other traditonal firewalls since the number of new TCP connections is controlled by the CPU not by the ParFlow.

    I wish those who are good at FPAG should consider the SYN attack in your design.

52. 阿土仔 于 2011-03-24 2:34 上午

    关于SYN attack Multithreaded 是什么意思？FPGA实现syn attack的防范是很容易的

53. multithreaded 于 2011-03-24 5:52 下午

    According to the Chinese description, a packet is first sent to the CPU …, i.e., a TCP connection was processed by CPU not by FPGA. Only after a connection is established, the FPGA based Pakflow will take it over. Got it?

    Please read between lines and the Devil is in the details.

    Of course, other firewall designs in the market more or less share the same deficience.

54. multithreaded 于 2011-03-24 5:58 下午

    >FPGA实现syn attack的防范是很容易的

    How do you know a system is under SYN attack?

55. 阿土仔 于 2011-03-24 6:47 下午

    Pakflow的网站上也描述了FPGA实现了syn cookie来防御syn flood攻击。

56. multithreaded 于 2011-03-24 7:59 下午

    If a sender doesn’t support sync cookie, what would happen?

57. 剃刀 于 2011-03-24 8:13 下午

    fpga实现RSS很灵活，可以通过五元组hash+CPU 队列的空满情况来灵活判断。

58. txwwy 于 2011-04-06 9:30 上午

    测试了，目前只支持TCP\UDP 的加速，在我看来，只支持简单的NAT ,连QOS 都不支持。。。。。非常失望

59. SAAB 于 2011-04-25 7:39 上午

    这公司市场做的怎么样了？

60. chinomango 于 2011-04-25 5:06 下午

    这类方案不是问题，自有FPGA就有了吧？有人有了FPGA卡就可以作姜太公了。100G的FPGA卡也有呀。
    介绍很简短不好判断，只能以成败论英雄了。设计似乎还不算有创意。
    PCIe有40G的吧？目前这是上限。

61. roy 于 2011-05-25 6:57 下午

    看他们公司主页上面的拓扑图，fpga下面挂的是ddr2 sodimm，没有将sram设计进去

62. banboo 于 2011-06-23 2:20 上午

    dotslash 是高人。

63. 布雷德利 于 2011-08-11 1:40 下午

    完全和cavecreek 冲突，
    不看好，

64. Ezchip微码开发 于 2011-10-09 6:06 上午

    如果首包生成表项的逻辑不负责，有些NP自带的highlearn功能也可以实现啊，为什么现在好多都是用FPGA来做FastPath。根据我在路由器开发的经验FPGA编一个版本要好长时间很拖开发进度啊，呵呵。而且现在大部分的NP都带TM功能，上送报文给CPU的时候还可以做下控制，避免CPU被冲死。

65. smartdoit 于 2011-10-11 11:23 下午

    cavecreek还不稳定

66. alexzzp 于 2012-03-14 5:58 上午

    大家对那个netfpga10G的项目又怎么看呢？是否可以用他们那个10G的netfpga板卡做更多更有意思的设计呢？

67. 阿宝 于 2012-05-26 4:05 下午

    美亚柏科和启明星辰已经动手入股了。

68. Fastpath 于 2012-05-27 6:13 下午

    为了进一步丰富电子数据取证产品硬件研发能力和持续满足用户需求的能力；加大发展电子数据取证产品，提高盈利空间；提升电子数据取证产品的竞争优势，厦门市美亚柏科信息股份有限公司（以下简称“公司”）及启明星辰信息安全投资有限公司（以下简称“启明星辰”）分别以 100 万元人民币对杭州攀克网络技术有限公司（以下简称“杭州攀克”）进行增资.

    本次增资完成后，杭州攀克的注册资本变更为人民币 127.28 万元，杭州攀 克现有股东浙江浙大安达科技有限公司占杭州攀克注册资本的 78.58%，公司及启明星辰分别占杭州攀克注册资本的 10.71%。

69. Peter 于 2012-05-31 8:31 上午

    http://www.tilera.com/sites/default/files/productbriefs/TILEncore-Gx36_PB028-02.pdf

    给大家多一个选择，4万兆智能网卡，4 SFP+， 8GB DDR3，36个1.2Ghz CPU 支持40Gbps 64B fast path转发, PCIe 2.0 x8 ， 35G IPSEC@1500B 处理能力

70. Peter 于 2012-05-31 8:37 上午

    FPGA, NP, multicore, x86 各有优势，还是要量体裁衣选择自己合适的。 当然相互组合也是不错的方案，例如TILERA 众核+x86.

71. Patrick 于 2012-06-13 11:58 上午

    和整个 cavecreek 产品线冲突，不看好。

72. LI 于 2012-07-02 4:57 上午

    想想tolapai,intel也不是每件事都靠谱

73. 山东李 于 2012-07-02 9:14 下午

    这种架构在十年前，甚至更早的产品中就在使用了。事实证明，拿出这样的概念忽悠客户，打标还是不错的。至于实用性，我持保留意见。以前我们在O公司做过这样的产品。性能确实不错，但是软件功能的升级太快，怎么做好软件的功能跟硬件的性能两个优点都保留是考验的关键。

74. boyhill 于 2012-07-05 12:27 上午

    万兆安全产品没必要FPGA卡，x86配合intel 82599网卡完全够了，预研100G的吧，等x86带宽够了，就能用了。现在带宽增长这么快，国内骨干网40G
    POS 都已经有部署的了。

    多核x86方案优势在于运算性能，适合做应用类防火墙，比如内容审计之类的。万兆产品好多年前就有了，一般是双至强配合万兆网卡，主要应用在骨干网的内容审计，当然是安全部门的应用，现在一般省出口都上百条的10G POS线路，采用万兆方案能节省大量设备，现在这些系统最大的成本是存储还原的完整内容。实时分析处理，内容过滤，拦截tcp数据没问题的。

    x86弱点是包转发能力，intel 82599做这个也完全够了，现在网卡能结合cpu的多核，这不是以前单DMA网卡能比的。

    当然x86耗电量很大，发热大，用来做普通设备可能散热很麻烦。

75. cc 于 2012-07-05 8:36 下午

    FPGA做这类应用不看好！