批判材料: 泛腾众核平台方案

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




(没有打分)

雁过留声

“批判材料: 泛腾众核平台方案”有152个回复

  1. tim 于 2013-01-20 7:44 下午

    哈哈,首席实在看不下去了,直接标题就是批判材料,哈哈哈····徐鹤军自打自脸

  2. 泛腾电子-徐鹤军 于 2013-01-20 7:53 下午

    欢迎大家拍砖。

  3. aaa 于 2013-01-20 9:15 下午

    这个行业,未来几年,围绕x86和dpdk的架构,很可能更受欢迎。

  4. whowe 于 2013-01-21 1:10 上午

    由于大量继承的业务代码的并行能力短期较难提升,这个时候,主频,IPC,Cache 带来的好处,往往比使用更多的核的好处更明显,亲身体会,仅供参考。

  5. bbb 于 2013-01-21 3:48 上午

    没啥价值

  6. 泛腾电子-徐鹤军 于 2013-01-21 7:26 下午

    To Whowe:众核的定位是给Intel拾遗补缺,做一些Intel不太擅长的工作。我们的加速卡产品就能很好保护客户已有的开发,将部分耗计算资源的工作offload到我们加速卡上,从而提供单位空间的计算能力和效率。

  7. tim 于 2013-01-21 8:33 下午

    加速卡,cavium不是标准pcie插槽嘛,还需要做什么单独的加速卡产品?

  8. arthas 于 2013-01-21 9:16 下午

    徐总你们应该把硬件做的更稳定点.

  9. 泛腾电子-徐鹤军 于 2013-01-21 11:27 下午

    To Tim:Cavium 是做嵌入式处理器的,Tilera也是的。PCIe卡是一种产品类型。为了区别同样是PCIe接口的网卡,显卡,这类非特定功能的PCIe卡我们也叫他们加速卡。比如我们的众核PCIe卡用在视频编码领域可以叫做编码加速卡,用在网络数据处理领域,可以叫作智能网络加速卡。统称加速卡。功能是为主机卸载部分计算功能。

  10. aaaa 于 2013-01-23 8:08 上午

    http://item.taobao.com/item.htm?spm=a1z10.3.17-10395011.35.YCNhDR&id=16941594283&

    国内已经有类似成品在销售了

    36 核 6200 RMB ,买一台 来玩一下不错,不过自带的软件性能极其低下,GUI 倒是很好!就当开发板用吧

  11. 泛腾电子-徐鹤军 于 2013-01-23 5:54 下午

    欢迎更多的朋友尝试众核的产品。老玩Intel多没劲。相信逛弯曲的朋友都喜欢挑战新事物。

  12. kevint 于 2013-01-24 1:50 下午

    http://www.intel.com/content/www/us/en/processors/xeon/xeon-phi-detail.html

    intel基于knights cornor的产品马上就要上了。并且基于KC的加速卡已经在某大客户运行了1年多。
    tilera技术上没有什么不好的,而且mesh应该是领先的。但是感觉business上有没有足够的动力让客户换门是另一回事了。

  13. multithread 于 2013-01-24 9:34 下午

    不要玩众核了,管它是谁的!

    耍耍这个吧!

    http://it.21cn.com/mobile/news/a/2013/0120/11/20242086.shtml

  14. 泛腾电子-徐鹤军 于 2013-01-24 10:13 下午

    Intel KC 目前的产品型态还仅仅是加速卡的形式。众核的产品形态从加速卡到服务器到电信级的ATCA产品,有全系列产品线。

  15. multithread 于 2013-01-25 4:38 上午

    The last submission is still under approval. Why is it so slow?

    不要玩众核了,管它是谁的!
    耍耍这个吧!
    http://it.21cn.com/mobile/news/a/2013/0120/11/20242086.shtml

  16. 泛腾电子-徐鹤军 于 2013-01-26 8:59 上午

    To multithread:不玩36核的去折腾8核的,显不出您的才能吧。

  17. ChargePump 于 2013-01-26 4:25 下午

    Tilera 多核和 SSD 整合起来做大数据分析应该是个不错的方向,建议考虑

  18. multithread 于 2013-01-26 8:47 下午

    如果一个x86的核顶四个MISP核呢? 那我的8核岂不是32个核码?

    其实无论是多核还是众核,软件上的挑战是一样。当核的个数小一点时,相对来说好控制一点。

    要想说服大家,我来出两道题,请你们的专家回答一下:

    1。如果两个核之间用FIFO通讯,如何实现?
    2。如果想把报文均匀地分到不同的核上,如何把同一TCP连接上的报文分到同一个核上? Please note it is about TCP connection but TCP one way flow :-)

  19. 泛腾电子-徐鹤军 于 2013-01-27 2:25 上午

    一个x86的核顶四个MISP核呢?您测试过吗?何况还是ATOM 8核。看来您更喜欢PowerPC,单核可以到5Ghz,搞个双核就可以了。

  20. 泛腾电子-徐鹤军 于 2013-01-27 2:32 上午

    至于您的两个问题,我想高手早就解决了。因为一流的通信公司早就在用多核和众核的产品了。不要自己解决不了就觉得其他人都不行了。何况中国的计算机科研能力比国际还差很远。

  21. tim 于 2013-01-27 3:35 上午

    鹤军,人家问怎么分布,就事论事嘛,,,你老提国外什么的就算回避了问题是吗?

  22. wei 于 2013-01-27 5:36 上午

    众多简单多核的架构应该算是众多架构里面很早就有的一个选择,很多公司都有这样的产品,早期在一些ASIC用这样的架构。Tilera的独特地方是mesh架构。众核的方向和前景应该是不错的,具体每个核的能力应该放多大,是想intel I7, intel Atom,还是tilera的1.2G的VLWI,和应用有直接关系,也不能说哪个选择一定好吧。

  23. 泛腾电子-徐鹤军 于 2013-01-27 9:31 下午

    To tim:我对具体的如何实现multithread所提两个问题还真不知道如何回答,但是我查了些资料发现老外所发表的对于方面的解释来看应该是已经解决的multithread的问题了。可以在Google查查 SonicWall 发布的 Reassembly-Free Deep Packet Inspection 技术的说明。

  24. 泛腾电子-徐鹤军 于 2013-01-27 9:45 下午

    To Wei:各家有自己的长处和特点。没有最好只有合适。

  25. multithread 于 2013-01-27 9:45 下午

    小徐,学习要认真啊!尤其要与时俱进!

    除了是个SOC外,这里的ATOM非你通常理解的ATOM, 他支持:

    1。乱序执行
    2。SSE 4.2 指令集。

    好好学习后,再来抢答问题。

  26. multithread 于 2013-01-27 10:01 下午

    小徐,我知道你回答不出来我的问题! 我还知道Cisco,Juniper, Huawei etc. 在寻找比Intel的DPDK更好的解决方案。

    请不要Google了,这两个问题的”水“很深,请你们的专家或者Tilera的专家来回答吧!

    你不是说”中国的计算机科研能力比国际还差很远“码?这样做的目的不是要难为谁。 而是要通过真正的技术交流来推进一下对多核和众核的了解, 让我们在这个”坛子“人来讨论一下国际前沿的问题。

  27. 陈怀临 于 2013-01-27 10:58 下午

    小徐,回答问题要认真,谦虚。多线程是我的好朋友。你可以千万说话要注意呀。不要給我掉份儿。。。

  28. aaa 于 2013-01-28 6:28 上午

    如果SDN成为主流,那么谁会成为这个领域CPU的霸主?不一定是intel,比如ARM就通过不同的技术方向和商业模式,已经基本上让intel难以在这个领域出局,就像有人进入PC领域,一样,即使是AMD这样用尽浑身解数想接近intel的,即使intel在和64bit和多核上有失误,但及时修正后,仍然让AMD无计可施,这就是大象的威力。但是大象怕小老鼠,所以他打不过AMD的小弟弟ARM。所以在SDN时代,有另外一家多核/众核CPU执掌牛耳是可能的,不管intel是否是因为不愿意现在立刻投入这个方向,总之,目前intel只是其中的一个玩家,大家都还有机会,看谁能笑到最后。谁能更好的和SDN配合,取得商业上的成功,谁将是王者。

  29. jiyif 于 2013-01-28 5:38 下午

    to 26
    的确水很深,很多设备商在寻找替代方案,intel也在招人做开发和优化。dpdk固然不错,但也有其他方法实现dpdk一样的效能。
    各家关注的应用不一样,x86大奶的地位暂不可动摇。2奶自有2奶的活法,关键还是看你的应用是计算密集还是通讯密集型。在x86和np的中间地带,众核有其存在的必要。我更看重功耗,比如高清播放器 500M的cpu 整系统10w功耗也能做h264解码,就没必要用x86了。

  30. ayvuir 于 2013-01-28 5:51 下午

    multithread的两个问题好解决,但是在越多核的时候这两个问题引起的核间负载均衡问题不好解决

  31. 泛腾电子-徐鹤军 于 2013-01-28 6:26 下午

    To Multithread:本人一直在不断学习,与时俱进。一直以为Google是最好的老师,所以给你提醒RFDPI的存在。你的问题我回答不出来,但是我也告诉你,从目前查询的资料来看,是有人解决了。至于如何解决这是人家的商业机密。只想说明一点,你的问题对其他人不一定是问题。让我们一起不断学习,与时俱进吧。

  32. 泛腾电子-徐鹤军 于 2013-01-28 6:28 下午

    To 首席:我是如此诚实,谦卑。知道的就掏心掏肺的坦诚而出,不知道就直接坦白。好人难做,做个诚实的中国人难上难啊。

  33. multithread 于 2013-01-28 9:27 下午

    To #30, how to solve them? I don’t say there are no solutions. It lacks of high-performance solutions.

    你的下半句揭示了我为什么不敢在网络里用众核了!真不知道如何把这么多的核玩好:-(

    To #31, google出的白皮书可以当科普之用,要多读一些google出的学术论文(10页左右)。然后自己亲身做过,才会有体会。

  34. multithread 于 2013-01-28 9:33 下午

    To#29, 同意你的看法.

    小徐如果在多媒体领域推广众核,我会为你鼓掌加油的。但是在网络领域里,尤其是在网络的DPI领域里,应该是多核略占优势!

  35. equilizer 于 2013-01-28 10:15 下午

    To multithread:
    赞助小徐一把,回答multithread同学两个问题
    1)两个核之间通过共享内存的方式实现FIFO,使用tilera提供的msg queue API或者自己实现相应的数据结构
    2)可以利用Tilera CPU上的mpipe引擎,将流分派到各个CORES。dynamic flow、static flow方式完全基于session来进行分派,保证同一个会话分派到同一个core。

  36. yeeha 于 2013-01-28 10:51 下午

    to #33/#34, 请教一下, 为什么多核比众核略优呢?只是因为负载均衡,同步/互斥的原因吗?如果一个包从进来到出去完全由一个核来负责,同步互斥的需求就没多少了吧。这样好像不就是embarassing parallelism,正好适合众核吗?

    反倒是多媒体领域好像向量化更合适一点,众核有什么优势呢?

    谢谢

  37. tim 于 2013-01-28 10:51 下午

    这个帖子开始越来越深入了,呵呵,好的现象。
    鹤军其实人很直爽的,,,就是我感觉实话实说啊,鹤军对技术细节可能宏观上把握得住方向,细节上一些问题解释的不是很清楚,还需要努力

  38. Sting 于 2013-01-29 12:35 上午

    所谓批判,实际上就是说这个材料说了跟没说一样,只是忽悠;
    网络通信领域说白了就是做负载均衡的,这不是众核搞的定的,最起码现在的众核不行,你要让报文收发处理现在成熟的硬件加速搬到众核上,简直是噩梦;众核的能力还是体现在小颗粒的计算密集领域,比如多媒体算法处理等,而且一旦大粒度的深度处理,就需要跨核分摊,对软件的影响也是核心设计之一;别跟我说什么众核上搞SMP,那个更是垃圾;
    这是CPU选型最基本的东西,技术论坛上玩宣传就是找死

  39. equilizer 于 2013-01-29 7:10 上午

    材料写得比较糙,但跟TileGx能否用于开发高性能网络安全设备无关。已知的情况,百度、新浪用于开发负载均衡产品;绿盟、傲盾用于开发anti-DDOS产品;百卓网络机框设备采用8颗GX36开发出 160G DPI、安全审计产品、上网行为、网关产品。

  40. 泛腾电子-徐鹤军 于 2013-01-29 8:12 上午

    非常高兴看到本贴渐入佳境了。

  41. 泛腾电子-徐鹤军 于 2013-01-29 8:24 上午

    To multithread:我不知你是否真正使用过众核产品没有,就如此武断说众核做网络不行,做多媒体还行。众核构架在学术界也是认可的。在中国也取得众多的网络应用成果案例。

  42. 泛腾电子-徐鹤军 于 2013-01-29 8:33 上午

    To Tim:能在宏观和微观都Hold住的唯有首席了。

  43. equilizer 于 2013-01-29 8:50 上午

    to 徐鹤军:
    小徐童鞋,别拍首席马屁哦。。。首席不好这一口

  44. yeeha 于 2013-01-29 9:18 上午

    达人们,

    我对于网络处理芯片的这些性能数据还没有什么概念。 比如多少Gbps的性能。有没有比较市面上现有的解决方案的比较(比如对于H/Z, CISCO, JUNIPER)的技术,性能上的比较?
    把所有的MARKETING噱头,政治杯葛抛开,现在的情况是什么样子?H/Z跟C/J的技术差距还有吗?有多大 ?

    谢谢

  45. aaa 于 2013-01-29 12:54 下午

    是人都喜欢马屁,关键看你拍没有拍到让人受用的G点上:)没找准G点,或敏感带,人家就可能不爽,甚至多了还很可能烦。我看好小徐同学,不敢说事业大成,至少小成是没多大问题的。小徐的技术和拍马的水平,都是在及格以上的。小徐,我看好你,加油哦!

  46. 陈怀临 于 2013-01-29 5:08 下午

    小徐有培养前途。。。是个好苗子呀。。。

  47. multithread 于 2013-01-29 5:42 下午

    To#35:
    >>1)两个核之间通过共享内存的方式实现FIFO,使用tilera提供的msg queue API或者自己实现相应的数据结构

    如果这样做和多核有什么区别? 为何不用onchip上所提供的硬件通讯机制?

    用软件做,有多快?

  48. tim 于 2013-01-29 5:44 下午

    哈哈,小徐是论坛2013年第一号娱乐人物

  49. multithread 于 2013-01-29 5:47 下午

    To#41, Tilera最早出道就是为多媒体而设计的,请把其创始人的学术论文google出来好好读一下。

  50. multithread 于 2013-01-29 5:59 下午

    〉〉可以利用Tilera CPU上的mpipe引擎,将流分派到各个CORES。dynamic flow、static flow方式完全基于session来进行分派,保证同一个会话分派到同一个core。

    在多核上,只有部分网卡上有支持RSS的功能,是针对一个端口来用的, 像Intel 82599。 但无法保证同一个TCP链接上的两条对称流会映射到同一个core上。 Endace的网卡能做到,但贵的让人买不起啊!

    能否介绍一下mpipe引擎?

  51. gchen 于 2013-01-29 7:12 下午

    会话distribution问题:
    mpipe如果只分析packet,不能查找会话,那就仅能处理非NAT会话。
    用带RSS功能的网卡只能解决部分应用场景,并且对NAT同样无效。
    FPGA+CPU是一种完整的高性能解决方案,但其成本,就不说了。
    不考虑RSS网卡,也不考虑附加硬件(mpipe,FPGA等),专门拿出一个CPU核也是一种方案。这当然是性能最低的(cache和会话表访问上都有问题),但在实践中,通过深度的软件优化,却是一种可以接受的方案。
    所以,没有适应所有场景的完美解决方案。设计时只能将各种情况都考虑到,按需选择。

  52. equilizer 于 2013-01-29 7:40 下午

    TO 47:
    没有真正意义上的onchip通信机制。这点跟多核是一样的。但灵活性很高,core可以跑zol模式,可以让某个核专注地做某个应用(DPI、NAT、creat session)。开发的难点在于,cores的管理、会话管理、core的任务分配,以及整个报文/会话处理流程的关键节点cores资源的均衡利用。我知道的情况,像百卓他们已有很成熟的应用经验。

  53. equilizer 于 2013-01-29 7:58 下午

    to 50:
    mpipe可编程,可以基于五元组对报文分类并定向转发到你指定的cores,上行流、下行流,只要是一个会话,就可以分到同1个core。

  54. equilizer 于 2013-01-29 8:04 下午

    to #51:
    mpipe最重要的一点是可以把packet按会话灵活地分到不同core,至于会话查找、会话处理,还得靠你在core上实现代码处理。在分流方面,mpipe你看成FPGA好了,但上手很容易。

  55. gchen 于 2013-01-29 8:15 下午

    若只能按packet,则mpipe无法将所有NAT会话的报文在CPU处理前分到同一个core上。这个是所有简单编程硬件(含RSS网卡)的共同弱点。将NAT会话的分流交给CPU,则是我前面所说的最低效的分流方式了。

  56. equilizer 于 2013-01-29 8:26 下午

    to 55,
    基于packet,基于session两种方式都支持。
    基于session比RSS强的地方,就是可以同一会话分到同一个core。原理很简单,举个例子,源和目的IP与或后再模N,结果一样放到一个core。FPGA做也是一样的。RSS弱的地方恰恰就在这里。

  57. equilizer 于 2013-01-29 8:46 下午

    to #55,
    sorry,刚才没有回答到你的点上。
    mpipe单独没法将NAT同一会话报文分到同一个core;但mpipe简单分流后,再借助ZOL core的通信,就可以保证同一个nat会话,最终分到同一个core,而且开销很小,可以忽略。
    本质上讲,跟DPDK类似的。
    相比较而已,tilera跟容易上手,开发周期更短,产品形态更灵活,功耗更低。

  58. multithread 于 2013-01-29 10:19 下午

    >>mpipe单独没法将NAT同一会话报文分到同一个core;但mpipe简单分流后,再借助ZOL core的通信,就可以保证同一个nat会话,最终分到同一个core,而且开销很小,可以忽略。

    我们也试图在多核上研究这种模型。但发现他还不如将所有会话的报文分到同一个core上, 然后在做分流的好 (#55提到的),原因是core-2-core的通讯开销是不可忽略的。

    暂时叫做 n X (n-1) vs. 1 X n 这两种模型把!

    所以关键的问题是,FIFO开销到底是多少? 几百 或几千 Cycles)?

  59. gchen 于 2013-01-29 11:59 下午

    看来tilera的众核在这些关键问题上,与intel多核相比不存在太大优势。如论用哪个平台,厂家的软件OS功力才是根本。
    国内厂商在移植原有运行于单核的OS的过程中,不管是用Intel还是Tilera,他们存在的技术短板和面临的困难基本是相同的。
    是DPDK更容易使用还是Tilera的SDK更容易上手?用过的才知道。
    国内有些厂家在用,也不知道他们的感受如何?希望能拿出来分享一下,这样我们也能知道Tilera是否可能是Intel之外的一种选择。
    至少从行业内公开的资料来看,x86多核设备的性能是遥遥领先众核的。绿盟貌似至少一年前就在用Tilera了,现在从公开的资料也看不出是哪款设备(绿盟高端设备是10G)

  60. equilizer 于 2013-01-30 6:07 上午

    to #58:
    FIFO的开销就是一次读写内存操作,几个cycles,
    会话的后续处理属于无锁操作,所以能获得很高性能。

  61. ttttt 于 2013-01-30 6:32 上午

    59楼对绿盟好像很关注啊 ,,,,,Tilera国内华为这些都在用,包括迈普的高端路由器也在用,,,但是实在看不出Tilera在目前实用领域比多核性能高出多少。
    倒是功耗,成本,相对intel还是有一定优势

  62. equilizer 于 2013-01-30 6:35 上午

    to #59说得对。
    如果做完整功能的FW/IPS/UTM/LB/行为管理/流控,不管走DPDK还是tilera的路子,开发周期都得1年以上。整套代码几乎得重写、重测。
    如果特殊应用,比如IDC非法信息过滤、防DNS攻击、L4负载均衡、https转http等,在tilera上开发,可以在比较短的周期获得很高的性能。

  63. jsk 于 2013-01-30 5:59 下午

    62楼说错了,
    DPDK开法不需要重写和重测,,相反大部分代码不需要重写

  64. 新手0 于 2013-01-30 7:47 下午

    to #50:
    RSS不能做到双向的报文映射到同一个core上,根本的原因在哪里?
    是因为RSS的hash算法不保证hash(a->b)=hash(b->a)吗?

  65. 新手0 于 2013-01-30 7:59 下午

    RSS在某些应用场景下确实不太方便,比如在VLAN、PPPoE等场景,由于存在一个偏移,导致网卡(82599)不去做RSS,只能采用软件的方法来负载。
    不知道其它平台是否可以很方便的定义这个偏移?

  66. 泛腾电子-徐鹤军 于 2013-01-30 8:05 下午

    To multithread: 经Google发现如下信息: Anant Agarwal, Liewei Bao, John Brown, Bruce Edwards, Matt Mattina, Chyi- Chang Miao, Carl Ramey, David Wentzlaff. “Tile Processor: Embedded Multicore for Networking and Multimedia.” Hotchips 2007.

  67. 泛腾电子-徐鹤军 于 2013-01-30 8:10 下午

    To multithread:即便退一步说Raw项目当初目标市场是多媒体,也不能说现在的Tilera就不适合用作网络处理了。伟哥当初还是为治疗心脏病开发的呢,现在不也是全世界男人的最爱吗?您的这种论调与您一贯主张与时俱进可不符啊。

  68. 泛腾电子-徐鹤军 于 2013-01-30 8:12 下午

    To gchen:与其想了解别人的体验,不如自己体验一吧

  69. kendo 于 2013-01-31 1:55 上午

    在多核上,只有部分网卡上有支持RSS的功能,是针对一个端口来用的, 像Intel 82599。 但无法保证同一个TCP链接上的两条对称流会映射到同一个core上。

    ——————
    只要保证了rx和tx使用同一个hash值计算,把rx/tx的中断分散开后,将相同的hash值对应的rx的cpu和tx的cpu指定为同一个cpu就可以实现了吧?

  70. 不要为技术而技术 于 2013-01-31 2:18 上午

    即使从研发角度出发选择CPU,其实选择的不是微观技术方案优劣,而要选择的是技术变现成产品时的综合成本。原厂商在对架构平滑演进的承诺和能力,软件开发社区的大小,硬件供应商的可替代性,这些直接决定了产品的技术竞争力、运营成本和项目成本。任何一条拿出来都是比会话管理、核间通信、制程等等等等要重要得多的理由。做产品不是做技术玩具,如果Tilera存在像当年RMI一样被连续卖掉的风险,谁敢基于他家做3年的产品路标? 如果Tilera的盒子只有一个国内供应商,谁敢承担大项目供货的风险?如果Tilera全中国只有不到100个开发者,谁不担心这些研发牛人成本月月暴涨?与其纠缠在大同小异的技术细节上,不如踏踏实实把生态链做好。

  71. gchen 于 2013-01-31 10:31 下午

    楼上说的极是。
    当年天融信用RMI的东西,花了大量时间人力,产品快做出来的时候,RMI卖给NetLogic了。后来这个项目在快完成的时候黄了,成品也没出现过。相信Tilera也曾在天融信的视野出现过,不过这次他们吸取了教训,坚定地用了Intel的多核。
    这是比技术细节之外更重要的东西。

  72. 泛腾电子-徐鹤军 于 2013-01-31 11:23 下午

    To 70楼:说的非常好。用过众核平台的用户对于众核开发模式和环境都是有非常深刻的认可。融合标准Linux SMP开发模式和实时系统的ZOL功能让客户能够充分利用已有的Intel平台的Gcc的开发资源和经验快速迁移和实现他们的业务需求。这也是英特网公司敢于采用众核产品的原因。我没有听取说有英特网公司采用cavium和RMI做应用的,而这类公司采用众核平台这已经说明了众核平台开发的便捷和通用。

  73. multithread 于 2013-02-01 3:52 上午

    #FIFO的开销就是一次读写内存操作,几个cycles,

    读到这句,研究体系结构的人都笑了:-) 打回去,重测。

  74. multithread 于 2013-02-01 3:53 上午

    是的,RSS定义的hash算法不保证hash(a->b)=hash(b->a)。

  75. multithread 于 2013-02-01 3:59 上午

    小徐,请从1997的论文学习开始。 至少读完了一半的论文,我们在讨论好码?

    http://groups.csail.mit.edu/cag/raw/documents/

  76. faceless 于 2013-02-01 4:19 上午

    multithread有公开的联系方式吗?

  77. multithread 于 2013-02-01 2:07 下午

    还是觅名的好,可以“胡侃”、“神聊”。

    如果有需要,让陈首席转一下邮件吧!

  78. 泛腾电子-徐鹤军 于 2013-02-02 7:15 上午

    To multithread: 与时俱进好吧。我们讨论的是当前的众核Tilera,不是Raw Project。 “Tile Processor: Embedded Multicore for Networking and Multimedia.”

  79. yeeha 于 2013-02-02 6:28 下午

    问个问题, “Tile Processor: Embedded Multicore for Networking and Multimedia.” 里的第8页的这句话是什么意思?

    ”Combined L2 caches of all tiles act as
    distributed 4MB L3 cache“

    TILERA跟QFP/QFPII 比起来怎么样? 有的一比吗?

  80. yeeha 于 2013-02-02 6:29 下午
  81. aaa 于 2013-02-03 7:54 上午

    To Yeeha

    我们也研究过Tilera, 跟QFP相比就是开发太难了.而且号称100核, 实际产品没有的..

    而且我们一直担心Tilera的产能问题, 肯定满足不了我们需求的.

  82. yeeha 于 2013-02-03 11:30 上午

    to aaa, thanks a lot. can you give some detailed insights about the programmablity issues? With the customized memory hierarchy, ad-hoc parallelism to explore, the programmability issue of today’s manycore ASIC is always there. I would boldly guess QFP has similar idiosyncrasies in Programming. And QFP is also manycore. why tilera is particularly difficult? thx

  83. 泛腾电子-徐鹤军 于 2013-02-03 6:27 下午

    To yeeha:你问得太好了,看来你是个非常认真负责的人。你问的两个问题估计哪些对manycore有成见的人是回到不出来的。

  84. 泛腾电子-徐鹤军 于 2013-02-03 6:31 下午

    To 79楼:意思是其他tile的L2 cache是当前这个tile的L3 cache.

  85. 泛腾电子-徐鹤军 于 2013-02-03 6:33 下午

    To yeeha:我们公司可以提供免费的测试样机给你做评估。是否好用自己试过就知道了。至少你不是个白老鼠。国内采用众核的公司很多了。

  86. 泛腾电子-徐鹤军 于 2013-02-03 6:38 下午

    To aaa:敢情您用过QFP?没听说QFP还销给其他公司用。想必您一定是CISCO或者在CISCO呆过的吧。

  87. kevint 于 2013-02-04 1:33 上午

    to 79
    tilera是directory based的cache,如果一个core 的l2 miss,会去directory查这个数据在不在别的L2里面。所以virtually就是一个大L2。

    对于82,我个人猜测这些个np如QFP当初设计都是pipeline的。拿asic的设计思路去套GPCPU的编程模型,实际上把硬件很多detail扔给了软件。技术上没什么行不通的,只是每一个芯片都得养几百号人去开发维护,这不科学:)

  88. aaa 于 2013-02-04 3:03 上午

    to 徐先生。还在cisco。下一代isr和asa都考虑过,但因为开发和产能的关系淘汰掉了

  89. 泛腾电子-徐鹤军 于 2013-02-04 6:03 下午

    To aaa:据我知道CISCO已经有产品采用Tilera的芯片了。CISCO也是Tilera的投资方。您推荐一款CISCO专用的QFP给别人也不厚道啊,要人家眼馋啊。

  90. 大米 于 2013-02-05 6:25 下午

    hash(a->b)=hash(b->a)
    RSS是可以做到这一点的
    RSS算法是固定的,但是key是可以配置的。
    key一共是40字节,RSS random key register(RSSRK)。RSSRK如果是重复的16bit,那么hash(a->b)=hash(b->a)。
    RSSRK是重复的16bit,RSS hash的值域也会随之减少。如果RSS hash的结果只是用来索引RSS queue,那么没有问题,因为RSS queue不会超过16个。如果想用rss hash来做session的hash,那么就有问题。

  91. 大米 于 2013-02-05 6:40 下午

    在nat的情况下如果要保证session的两个方向进同一个RSS queue,可以有以下的一些方法供大家探讨。

    1,如果nat的时候端口不受限制,象symmetric snat。可以在选择端口的时候根据rss 算法计算rss queue的值,保证连接的两个方向hash到同一个rss queue。

    2,如果nat的时候端口受限,dnat/cone snat/static snat。82599有flow director.
    flow director有两种,perfect filter和signature filter。能够对五元组和vlan定义过滤器,过滤报文到一个rss queue中。perfect filter是完全匹配,signature filter匹配的时候能够加掩码。perfect filter与session 表很像,问题是数目不够。perfect支持8K,signature 支持32K。intel的人之前有说过新的芯片中会把flow director数目扩大。
    可以考虑用flow director作为session cache使用。当前最活跃的连接使用flow director来分流。

    3,软件分流。
    以上不能覆盖的情况,还有象ip 分片重组,ipsec解密,这两种情况RSS只能根据ip地址来选择 rss queue。

  92. 大米 于 2013-02-05 6:51 下午

    session的两个方向由一个core来处理。
    要看系统设计中这个需求是一个硬需求还是软需求。

    硬需求:
    每个core的地址空间是完全隔离的,session表不共享。但是这个情况不只是session的两个方向要由一个core来处理。alg的所有连接也必须由同一个core来处理。分发的core需要的信息太多,很麻烦。有的时候协议识别或IPS等模块需要多个连接的信息,这也没法做。

    软需求:
    session表是在各个core间共享。两个core同时处理一个session从系统架构上没有问题。但为了性能考虑,减少或避免锁,improve cache locality,一般可能是这种情况。

  93. Sailing 于 2013-02-06 6:52 下午

    此帖好热闹,留个名。

    1. 如果两个核之间用FIFO通讯,如何实现?
    2. 如果想把报文均匀地分到不同的核上,如何把同一TCP连接上的报文分到同一个核上?

    感觉直接用x86和Tilera都很难解决这两个问题。
    第一个问题。我现在想得有点多,不敢回答。
    第二个问题,Multithread研究的如何了?我之前研究过很长一段时间这个问题。理论上几乎不存在这样的东西,除非用一个核。如果针对某个特殊场合,可以找到一些次优的算法。

    越来越觉得众核解决这些网络上的东西乏力,做做LINPACK还是不错。

  94. multithread 于 2013-02-07 1:19 上午

    To #90:

    用Intel 82599 中的RSS,是可以选择 (IP_src,IP_des, Port_Src, Port_Dst, Proto) 等域名来定义Key的。

    但是,这是一个有序的问题。即来自两个方向的 (IP, Port)是反向的,所以得出的HASH值是不一样的。

  95. multithread 于 2013-02-07 1:28 上午

    To #91, Flow director 无法在大数据中使用。 32K的TCP流量对10GE的port来说太小了。

    如果还要考虑IP fragmentation, 这个问题就变得“水”很深了。 所以大家在选择系统方案时一定要谨慎、再谨慎。

  96. multithread 于 2013-02-07 1:32 上午

    to#93, 我也只会用一个核来接受,然后再转发给其他核来处理, 即前面提到的 1xN 模型。

    这个问题用一块 FPGA 来解决,效果最佳!

  97. 大米 于 2013-02-07 3:05 上午

    to 94:

    不是这样的。RSS HASH是Toeplitz hash。
    可以配置一个40字节的key(RSSRK 寄存器)。如果这个key是两字节重复的话,
    在非nat情况下,一个session的两个方向的hash值是一样的。
    http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf

    nat情况下,对端口可控的可以算出一个端口来保证两个方向hash值一样。
    端口不可控的(cone snat, dnat…)可以用flow director来做一个最活跃连接的cache。其余连接仍然用cpu分发。

  98. multithread 于 2013-02-07 7:31 上午

    修改RSSRK的想法很妙! 我们会立即做试验来验证文章中的提法是否可行。

  99. 大米 于 2013-02-07 7:04 下午

    ntop有一个DNA(direct nic access)项目。DNA和DPDK很像。其中的一个feature也是symmetric RSS。

    http://www.ntop.org/pf_ring/hardware-based-symmetric-flow-balancing-in-dna/

    DNA项目里面的一些BLOG还是很有趣的,像以下这个。我在调试X86系统性能的时候也遇到了不少关于内存带宽方面的优化问题。

    http://www.ntop.org/pf_ring/not-all-servers-are-alike-with-dna/

  100. 泛腾电子-徐鹤军 于 2013-02-08 3:18 上午

    非常感谢这么多朋友来批判。祝大家新年快乐,我会在2013年继续接受大家的批判,不悲不亢。

  101. multithread 于 2013-02-10 5:18 下午

    首席这个“坑”挖的挺深,至少把“多核”的绝技现了行了。

    希望“众核”的“砖家”们,在2013里也亮亮相,不要让小徐替你们挡子弹了!

    希望这个讨论,超过”盛科“的争论,成为中国 multi-core vs. many-core 的经典PK! 然后,再让首席把它翻译成”洋文“,成为世界的经典,把”坑“给首席先挖好!

    新春快乐!

  102. aaaa 于 2013-02-14 7:29 下午

    97 楼是好办法!

  103. 泛腾电子-徐鹤军 于 2013-02-16 6:52 下午

    To Multithread:大年初一就来一拜年贴,太客气了。奖你一个大奖章。

  104. 新手0 于 2013-02-17 7:45 下午

    谢谢97给出的方案,一个小问题,特殊构造的RSSKey会不会影响Hash结果的分布?

  105. 新手0 于 2013-02-17 7:46 下午

    不好意思,论文中提到了,We also
    show that our symmetric RSS scheme does impair load balancing among the available CPU cores.

  106. Peter 于 2013-02-19 7:34 上午

    Tilera Announces TILE-Gx72, the World’s Highest-Performance and Highest-Efficiency Manycore Processor
    * Reuters is not responsible for the content in this press release.
    Tue Feb 19, 2013 9:00am EST
    SAN JOSE, CA, Feb 19 (Marketwire) —
    Tilera(R) Corporation, the leader in 64-bit manycore general-purpose
    processors, today announced the TILE-Gx72(TM) processor with 72
    power-efficient cores coupled with massive I/O and four high-performance
    DDR3 memory controllers to drive the next-generation of network,
    multimedia and cloud infrastructure.

    Tilera’s customers are building the intelligent infrastructure for
    tomorrow’s hyper-connected, mobile networks and the amount of real-time
    data and video content is growing exponentially each year. Substantially
    more complex services are being offered, and the rapid pace of new
    feature additions demands a software-based model with familiar,
    standards-based programming tools. Further, OEMs are insisting on
    dramatically higher levels of performance and scalability from their
    processor supplier.

    In less than a year from the launch of its market-leading TILE-Gx36(TM)
    processor, Tilera is doubling the compute performance, doubling the I/O
    capacity, and continuing the linear scaling of application performance
    with increasing core-count that is the hallmark of the Tile architecture.
    The TILE-Gx72 leverages Tilera’s many innovations — including the
    iMesh(TM) 2-dimensional interconnect, DDC(TM) distributed coherent cache,
    and TileDirect(TM) direct-to-cache I/O — to deliver the highest
    compute-per-watt efficiency of any multicore processor in its class.

    “The TILE-Gx72 rounds out our processor portfolio, complementing our 9,
    16 and 36-core TILE-Gx processors and is offering a remarkable range of
    processing performance,” said Devesh Garg, president and CEO of Tilera.
    “Customers demand ever-increasing levels of performance and
    performance-per-watt to stay competitive and they simultaneously want to
    reuse their software and hardware investments across their product
    portfolio. The TILE-Gx72 brings an unprecedented amount of compute to
    customer designs, and leverages thousands of open source libraries and
    the growing Linux ecosystem.”

    The TILE-Gx72 is ideally suited for compute and I/O-intensive
    applications including:

    – L2-7 networking and firewall appliances
    – High throughput SDN (Software Defined Network) computing
    – Network monitoring and analytics with 100% line-rate packet capture at
    100 Gbps
    – Layer 7 Deep Packet Inspection (DPI) at over 50 Gbps
    – Compute offload NIC (Network Interface Card)
    – Intrusion prevention and detection (IPS/IDS) at over 20 Gbps
    – “Big Data” transaction processing at over 4 million transactions per
    second
    – Streaming video server/content delivery networking offering 50 Gbps
    HTTP streaming
    – HD video conferencing with dozens of H.264 1080p encode/decode
    channels

    “We continue to be impressed with the scalability of the TILE-Gx
    family with its seamless software compatibility from 9 cores to 72
    cores,” said Ofer Raz, head of platforms and architecture of Check Point
    Software Technologies. “The TILE-Gx72 processor brings the right mix of
    compute, low-latency I/O, memory bandwidth, and accelerators for the
    needs of our intelligent, integrated security appliances.”

    “Tilera is raising the bar again with the launch of its flagship
    Tile-Gx72 processor,” said Linley Gwennap, principal analyst of The
    Linley Group. “As the first 64-bit, manycore processor to run standard
    SMP Linux across 72 cores on a single chip and capable of 100Gbps
    networking, the TILE-Gx72 will enable customers to achieve new levels of
    performance in multimedia and networking applications.”

    TILE-Gx72 Technical Highlights
    The TILE-Gx72 is a full System-On-a-Chip
    (SoC), integrating a broad set of I/O’s and memory controllers to reduce
    system cost and save on printed circuit board area.

    – 72 64-bit processor cores – Powerful three-issue cores, designed for
    ultra-high power efficiency. Each processor core integrates L1 and L2
    caches and supports virtual memory and multiple privilege levels
    – iMesh(TM) two-dimensional multi-tier interconnect – Over 110 Tbps of
    bandwidth interconnecting cores, caches, I/O devices and DDR3 memory
    controllers
    – 23 Mbytes of on-chip cache – Distributed coherent L3 cache with ECC
    protection and Tilera’s patented DDC(TM) technology
    – Extensive integrated I/O:
    — Eight 10Gbps Ethernet ports, configurable as 32 1Gbps ports
    — Six PCI Express ports with 24 lanes of SerDes
    — Four on-board DDR3 memory controllers delivering more than 475
    Gbps (60 GB/s) of bandwidth and supporting up to 1 TB of attached
    memory
    – mPIPE(TM) packet processing subsystem – Delivers C-programmable
    wire-speed packet classification, load-balancing, packet ordering and
    buffer management for ingress and egress traffic at over 240 million
    packets-per-second
    – More than 40Gbps of crypto acceleration – MiCA(TM) subsystem
    supports a wide range of security protocols such as SSL, IPsec, SRTP,
    MACsec, 3GPP and also accelerates functions such as data deduplication

    Availability

    The TILE-Gx72 devices are available for sampling.
    Please contact pliang@tilera.com

  107. session-table 于 2013-02-19 8:46 上午

    箱知道大米所提到的session这个概念有多少公司在用?貌似不是很多。

  108. 青锋剑 于 2013-02-20 6:11 上午

    对Tilera不能用常规的SMP的思路去理解和应用,Tilera的前身RAW项目的初衷是Soft ASIC.基本思想是利用众核核多和片内Mesh高带宽的优势,将部分CPU core做成应用需要的加速Engine,就像Cavium芯片中的硬件加速模块一样,然后再此基础上做应用框架的开发。利用一个或多个CPU做基于软件的加速Engine,就是Soft ASIC的含义。优点是非常灵活,开发快,缺点是对特定应用性能不如硬件加速模块,这就是为什么Gx增加了mPipe和Mica的原因。回答MT核间FIFO通信的问题,Tilera的CPU核之间可以用Register-Register通信的,可以不用共享内存,不过Cache,就像FPGA内的模块的通信方式,所以用好了可以很快。

  109. multithread 于 2013-02-22 8:30 下午

    >>Tilera的CPU核之间可以用Register-Register通信的,可以不用共享内存.

    如果不是硬件的FIFO,软件上如何控制? 最好协调producer and consumer?

  110. multithread 于 2013-02-22 8:38 下午

    强调核越多越好的人,请读一下:

    “Power Challenges May End the Multicore Era”, By Hadi Esmaeilzadeh, Emily Blem, Renée St. Amant, Karthikeyan Sankaralingam, Doug Burger
    Communications of the ACM, Vol. 56 No. 2, Pages 93-102

    The scary prediction: at 8nm, the percentage of dark silicon in a fixed- size chip grow to 50%.

  111. kevint 于 2013-02-22 11:15 下午

    估计过个8年10年graphene chip就出来了。。。

  112. 根本不相干 于 2013-02-23 7:59 下午

    session负载均衡问题(不一定仅限于tcp),前面大米总结的比较清楚,(当然flow director,以及类似的在外设硬件上部署flow table的方案不具备太大实际商用价值)

    1)简单报文封装:对rssrk的灵活应用
    2)nat/sbc的本地端口分配可控场景:控制面参与使得分配的端口满足hash结果映射一致
    3)端口分配不可控,或复杂报文隧道格式:依靠单独的core搞定负载均衡。其中端口分配不可控问题可以结合hash和core再分配:先随机hash,再remap一次,可以做到类似对称的模型无需1:N(但隧道无法这么做,底层硬件完全没法处理)

  113. Peter 于 2013-02-25 6:59 上午

    Procera Networks and Tilera Unleash 200Gbps Deep Packet Inspection Solution
    Industry-Leading, Agile and Scalable Performance Achieved With Procera NAVL OEM DPI Engine and Tilera’s TILE-Gx Platform

    Press Release: Procera Networks – 3 hrs ago
    Email
    ShareTweet
    Print
    BARCELONA, SPAIN and SAN FRANCISCO, CA–(Marketwire – Feb 25, 2013) – (Mobile World Congress and RSA) Procera Networks, Inc. (NASDAQ: PKT), the global intelligent policy enforcement company and Tilera Corporation, the leader in 64-bit TILE-Gx™ manycore general purpose processors, today announced they have achieved 200Gbps of Deep Packet Inspection (DPI) performance deploying the Procera Network Application Visibility Library (NAVL) on TILExtreme-Gx™ Duo platform, utilizing approximately 70 percent of the TILE-Gx cores.
    This industry-best performance addresses the growing requirements of telecommunications and enterprise security providers to implement application-aware policies to efficiently manage their networks without sacrificing user quality of experience (QoE). The solution can be deployed in a variety of networking scenarios including Network Security (IDS/IPS, DPI, DLP), Cyber Security, Network Monitoring, Data Forensics, Analytics and Big Data processing.
    “With traffic volume and application types exploding in service provider and enterprise networks, there is a growing demand for high-throughput, accurate and real-time DPI to enable network optimization and tiered billing,” said Jason Richards, senior vice president of business development for Procera Networks. “The accuracy and breadth of applications and protocols supported by the Procera NAVL DPI engine, coupled with the 200Gbps throughput we have achieved on the TILE-Gx, is the perfect solution to meet this rapidly growing and complex demand.”
    Tilera’s TILExtreme-Gx Duo platform packs 288 cores with eight TILE-Gx36™ processors in a compact 1U rack mountable device. The TILE-Gx manycore processor ranges from 9 cores to up to 72 cores, and is available in various form factors from half-length PCIe cards to 288 cores in a 1U chassis. This enables customers to choose 5Gbps, 10Gbps, 40Gbps, 100Gbps or 200Gbps DPI solutions depending on the overall solution requirements.
    “We have once again shattered the record books by delivering the industry’s highest performance per watt DPI solution with our TILE-Gx 64-bit processor,” said Michael Zimmerman, vice president of marketing for Tilera Corporation. “Our focus on standard software programmability, maximizing performance per watt and scalability enabled us to deliver such high performance. Further, this solution utilizes about 70 percent of the available processing on the platform, leaving the rest for other functions — such as billing, policy enforcement and end user customization.”
    Procera’s NAVL is an easily integrated DPI engine, providing real-time, Layer-7 classification of network application traffic. NAVL enhances telecommunications providers’ abilities to provide a variety of application-aware functions to ensure equitable access to resources by all users and to create tiered classes of service for billing. Procera’s NAVL DPI engine and OEM products are the result of its recent acquisition of Vineyard Networks.
    Tilera and Procera Networks will demonstrate these capabilities at Mobile World Congress in Barcelona at the Fira Gran Via, February 25-28, 2013 in hall 5 stand 5I10 and at RSA in San Francisco at the Moscone Convention Center, February 25-March 1, 2013 in booth #2739.

  114. Peter 于 2013-02-25 8:51 上午

    Tilera’s TILE-Gx Powers AhnLab’s DDoS Protection System (DPS) Appliances

    “Together with Tilera, we are delivering one of the industry’s highest-performance and most extensive DDoS protection systems,” said Philip Kim, president and CEO, AhnLab. “The immense computing power, scalability and standard programming environment provided by the TILE-Gx family enables AhnLab to add our differentiated features with increased time to market advantages. This makes the TILE-Gx processor family the obvious choice to power AhnLab DPS appliances.”

  115. multithread 于 2013-02-25 5:55 下午

    Tilera的牛人们,请解释一下:

    1。 What Is TMC queue?

    2. If detect-per-pipeline is 3, how to assign the packets of the same TCP connection to the same core if three cores are used?

    ———————-
    Configuration options for Tilera (YAML format)
    # Tilera runmode configuration. for use on Tilera tilegx tile:
    # Number of parallel processing pipelines
    pipelines: 6
    # Number of detect threads per pipeline
    detect-per-pipeline: 3
    # Inter-tile queueing method (“simple” or “tmc”)
    queue: simple
    # Use tilegx mica for zeroing memory
    mica-memcpy: no

  116. 青锋剑 于 2013-02-25 8:11 下午

    俺不是Tilera的牛人,但试着回答MT 115楼的问题,抛砖引玉是俺的目的。
    1, TMC代表Tilera Multicore Components。TMC中的FIFO实现有2种,基于内存的和基于iMesh的。按照功能又可以分为单发单收(FIFO),多发单收(FIFO)和单发多收队列(queue)等。关于iMesh和MT关心的FIFO设计原则,性能,网上有一篇文章讲的非常清晰。这里就不多言了。
    http://www.princeton.edu/~wentzlaf/documents/Wentzlaff.2007.IEEE_Micro.Tilera.pdf

    2,Gx网络接口部分有个C编程的包分类器(mPipe),
    在指令预算内,可以按照应用需求优化,比如TCP的流分类和Hash,这个比Cavium和QorIQ目前的设计灵活。mPipe可以将分类的结果写入包头提供给应用,并指示Load Balance用分类结果查表后放入指定队列,后面的core从不同的队列取报就可以了。Tilera的报硬件队列不多,好像是64个,这点不如QorIQ的QM设计,如果必要,一个办法是由CPU core做2次分类和分发,反正核多;还有一个办法是打回环,由mPipe做2次分类,cpu做分发,如果mPipe的处理能力还有剩余的话。

    3,弯曲经常提到的话题,包处理时cache优化问题,Tilera的构架会有更多的手段。由于iMesh的带宽很高,当core上的L2 miss时,允许先到设定的别的core的L2中看一眼,如果有,就取回,大约需要40-50 cycle,没有再到DDR中去读,大约需要80-100 cycle。这样当多个core组成pipeline时,如果pipeline的之间传递的信息不大,用iMesh直接传,如果比较大,iMesh传消息,内容放在上一级为下一级设置的cache中,避免内存访问。再大,就只好放到DDR了。常规的设计比较难做到这个优化。同样是流水线在Tilera的实现,包处理的流水线和H264的编码流水线就可以采用不同的传递方式。如果考虑到36核和72核的芯片,每个核都有512K的L2cache,加上iMesh的带宽,如果应用能优化片内信息的交互,减少对DDR的依赖,那这个应用Tilera就有机会跑出高性能。
    4,Tilera的CPU是VLIW构架的,64bit可以容纳2-3条指令,非常依赖编译器的编译优化,不支持运行态的乱序执行和寄存器重命名,分支预测有没有我忘了,因此Tilera的单核的IPC无法和MIPS,PPC,x86比,但由于功耗低,核的数量可以多很多。
    5,江湖八卦,听说做过FPGA设计的人理解Tilera的构架比做纯软件的人理解要自然些。

  117. multithread 于 2013-02-25 9:22 下午

    Thanks! I got the answer for the first question. On average Buffered channels take 150 cycles (mapped onto a static FIFO) that seems little bit high considering a HW implementation.

    In comparison, on an Intel IXP2800 it is about 12-15 cycles. However IXP has only one ring of FIFO consisting 16 cores.

  118. multithread 于 2013-02-25 10:13 下午

    >>还有一个办法是打回环,由mPipe做2次分类,cpu做分发,如果mPipe的处理能力还有剩余的话。

    我的第二个问题可能要靠二次分发来完成。但问题是如何做到把同一TCP连接的报文发给同一个core呢?这时候zero-copy如何实现?

  119. 青锋剑 于 2013-02-26 1:52 上午

    听过Tilera介绍,理解不一定全对。Tilera的PCIE和网口一样,也是按照流的概念设计的,从PCIE过来的数据使用和网口一样的Buffer管理机制,允许仅将包头发给mPipe,包本身放在DDR中。实现零拷贝。回环也可以这么理解。技巧是Tilera的Buffer管理允许预留部分空间给应用程序,比如预分配(128+32)个字节压入硬件堆栈,告诉硬件只用128个字节,那么剩余的32个字节可以留给用户。当处理回环时,处理这个报文的core可以将特定的cookie写在用户定义的空间内,如果mPipe的程序知道约定,这时mPipe可以根据cookie转发到core等待的硬件队列。从这个意义上讲,mPipe对软件来说是个性能非常好的message管理/分发模块。如果项目性能要求不高,又赶时间,那核间的message通信可以考虑用mPipe做管理和发送,模块清晰,也比较容易debug。

  120. tt 于 2013-02-26 10:01 上午

    实际上tilera的iMesh 好像不能像116楼说的 传递大量消息,若传递很容易导致堵塞,从而系统死掉,所以只能用共享内存方式

  121. multithread 于 2013-02-26 10:16 上午

    听起来使用的像类似S-buffer(M-buffer) 的报文管理机制。 这样做的难点在于 buffer 的管理比较难办。除非有硬件直接支持; 否则buffer的申请和回收将成为系统的瓶颈口。

    看了一下Tilera的介绍,好像也没有专用的buffer管理机制。

  122. 青锋剑 于 2013-02-26 5:23 下午

    Tilera Gx16:
    . Flexible buffer manager with 32 configurable memory domains

  123. multithread 于 2013-02-26 9:13 下午

    Domain concept is too general to have any value in design.

  124. multithread 于 2013-03-01 8:30 上午

    其实Tilera阵营的人应该从如见“优势”入手来“忽悠”, 比如: What is ZOL?

    如果有人能做一个 ZOL vs。 DPDK的PK,那就给网络的人指明了前进的方向了!

  125. multithread 于 2013-03-01 8:31 上午

    TYPO: 应该是“软件”优势。

  126. 青锋剑 于 2013-03-01 9:37 下午

    MT正解!Tilera从最早的RAW项目,到Tile64, pro,现在的GX。比较这几代芯片的特点,很有意思,
    1,L1/2$的增加,从8K/32K到Gx的32K、512K。
    2,iMesh的进化,iMesh的用途调整。
    3,Gx的硬件加速,mPipe, mica。
    4,Gx貌似增加了不少支持Multimedia和network应用的指令。

    一个感觉是Tilera从一个MIT的项目商业化的过程。从RAW的商业价值的茫然到TILE, Pro的尝试,到GX的相对清晰(例如x86的网络offload卡)。也花了不少时间。可问题是Tilera好像还没有得到那个Tier 1设备商青睐,做出一个发挥Tilera优势的Killer应用,听说为Cisco定制了9核的芯片,但不知道干啥,产品好像也还没面世。在目前多核的市场中,感觉Tilera需要的不仅仅是作为Cavium或RMI的替代方案,而且Tiera独立的指令体系也有些让人担心,大家都在往ARM上靠…

  127. 泛腾电子-徐鹤军 于 2013-03-04 9:58 下午

    To 青锋剑:泛腾公司在2013年开发出从PCIe加速卡到高端ATCA产品,基本覆盖市场需求的所有产品形态。这是真实市场需求对泛腾的要求,也是众核产品越来越多的被各种客户所接受的原因。至于Tilera有多少个Tier 1 设备商客户可以咨询Tilera中国的梁龙先生。

  128. multithread 于 2013-03-06 11:40 上午

    问一个简单的问题:

    开源的lampp (32bit) 在Tilera上的Linux能跑吗?

    32bit的程序在64位的MIPS上是如何做到兼容的?

    –Xinan

  129. multithread 于 2013-03-06 11:50 上午

    是否用 gcc -m32 就能在Tilera 64bit下的gcc编译32的应用,然后在64bit的运行环境下运行?

    很多Linux的开源软件还没有移植到64下,在Tilera如何解决?

    Tilera最近在Suricata上的进展让人“耳目一新”, 不知Suricata做产品还需要多大的工作?

    http://planet.suricata-ids.org/

  130. 泛腾电子-徐鹤军 于 2013-03-07 12:16 上午

    To multithread:LAMP 完全可以在Gx平台上运行。我们已经调试好 suricata + Apache+php+mysql+BASE 的标准开源IDS系统。完全在Gx36平台上运行。还可以运行JAVA程序

  131. 泛腾电子-徐鹤军 于 2013-03-07 12:18 上午

    开源软件编译后基本都可以在Gx平台上运行。

  132. multithread 于 2013-03-07 1:06 上午

    在64bit的运行环境下如何产生32bit的可执行文件? 是否像x86_64那样能在64位上运行32位的程序?

    LAMPP是32位的。。。

  133. kevint 于 2013-03-07 1:54 上午

    http://www.tilera.com/products/software/development_tools

    支持32bit library

    tilera也是从32bit扩展到64bit的。应该类似x86与mips

  134. multithread 于 2013-03-07 7:15 上午

    It still doesn’t say if 32bit executable can be run on the 64bit mode as a x86 a.out can run under x86_64???

  135. Seriously 于 2013-03-07 7:20 下午

    The performance of script processing on wimpy cores is a joke for sever load profile. The effort for parallel scripting engine is still in the domain of research. 32/64 does not matter that much.

  136. multithread 于 2013-03-08 1:20 下午

    What is your point?

    Are you saying suricata doesn’t run well on Tilera?

  137. multithread 于 2013-03-08 1:22 下午

    I am asking 32 vs 64 bit question is not for performance but compatibility.

    That is why X86_64 is so good at since one doesn’t need to worry about the issue of if an open source application cannot be run on it.

  138. Panabit 于 2013-03-08 6:06 下午

    难道不能用中文吗?这Chinese English ……

  139. haha 于 2013-03-08 8:45 下午

    习惯问题,无论母语还是外语最难的就是写了。不过这哥们的英文的确乡土气息弄了点

  140. multithread 于 2013-03-08 9:14 下午

    好吧, 用中文讲一遍。

    在64bit下跑32bit的程序不是性能的问题, 是兼容的问题。 在X86_64下, 从来就不用担心某个32bit的开源软件跑不起来。 在MIPS64下???

  141. 泛腾电子-徐鹤军 于 2013-03-12 8:14 下午

    To multithread:32位应用软件是可以在MIPS上运行的。mysql,apache,php,包括多款路由软件都可以通过从原代码编译后在Gx36的64位系统上运行。

  142. multithread 于 2013-03-12 8:27 下午

    小许: 你没读懂我的问题。。。

    32位的软件在MIPS32下能跑,但并不说明在MIPS64能跑。 即用gcc -m32 编译后,能在MISP64下跑吗?

  143. 青锋剑 于 2013-03-12 9:44 下午

    Tilera的指令不是MIPS的指令.
    http://stackoverflow.com/questions/6515358/what-instruction-set-is-used-by-tilera-microprocessors
    为MIPS编译的程序,不管是MIPS-32还是MIPS-64,都无法直接在Tilera的CPU上执行。
    用户感兴趣的开源软件需要用源代码重新编译。除了Java程序,Tilera最新的SDK增强了对Java的支持。

  144. softwind 于 2013-03-13 12:33 上午

    multithread ,小徐是商业路线,技术是个半罐子水,技术问题还是请小徐搬出公司技术口的人来回答吧

  145. multithread 于 2013-03-17 7:56 上午

    我个人觉得: 在Tilera上很难做到32位和64位的共存,原因是在VLIW上, 同一个WORD里要放什么样的指令是有限制的。 比如: 两个ALU,一个Branch, 一个memory. 如果再加上32位的切换, 指令集将变得太复杂了。

  146. multithread 于 2013-03-19 12:01 下午

    Cadence收购强化了什么? It is a DSP as I always said :-)

    “Tensilica的IP一直广泛运用于音频、图像处理、通信、无线、网络设施等领域,每年的营收增长率超过35%。难得可贵的是其核心理念多年来没有消失,并在不断寻找新的解决方案。

    ”黄小立如此评价Tensilica,“有些电子产品永远是需要DSP的,例如汽车运用中的实时高速数据处理。”无疑,本次收购完成后将强化Cadence在高速数据处理领域的话语权.

  147. multithread 于 2013-03-19 12:07 下午

    If Tensilica is only worth of $380M, how much is Tilera worth?

  148. kevint 于 2013-03-19 5:59 下午

    What’s the point?

  149. yihuazhu 于 2013-05-08 1:54 上午

    to50#:82599可以做到tcp两个方向中断到1个core上

  150. jiay 于 2013-06-04 8:25 下午

    大米给出的是干货

  151. jianghe 于 2013-06-18 10:16 下午

    1. 我是来顶徐总的,怎么也算合作了一把。
    2. @大米, flow-director占用网卡的receive-buffer的,不知道你注意到没?
    3. 采用flow-directo做cache的思路建议产品化的就不要用了,玩玩可以
    4. tilera用cpu做软加速的思路我挺喜欢的,前面有提到用FPGA做的,我建议还是算了,真心累啊。能做软件做就用软件做吧,除非你的需求很简单很简单。
    5. 很奇怪我google搜索macsec会看到这个帖子,完全不相关啊。

  152. huangjm 于 2015-11-02 1:19 上午

    #FIFO的开销就是一次读写内存操作,几个cycles,

    涉及cache coherency的共享内存读写,几个cycles搞不定吧?