多核处理器下的快速包处理软件架构FastGate

作者 | 2012-08-06 15:28 | 类型 移动互联网, 移动和设备, 通讯产品 | 49条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




陈首席，各位弯曲的老友们，大家好。关注弯曲多年，受益颇深。我们来自ASTRI（香港应用科技研究院），是一群热爱系统设计的大宋子民，所在的项目组专注于多核处理器下的快速包处理的软件研发，逐渐形成了一套高性能、高可扩展性的软件架构FastGate，特在此跟大家分享和探讨。

FastGate主要的目标是帮助用户缩短研发周期，保护已有的代码，快速开发和灵活部署自己的业务。用户无需关注多核处理器的硬件细节、无需关注性能和扩展性，只需专注于自身功能模块的开发，然后通过和FastGate框架的无缝集成便可以快速形成自己独有的产品，推出市场，同时又可以根据业务需要，灵活的扩展。

FastGate框架的的设计和SDN & OpenFlow的思想很吻合。主要特点如下：

（1）控制平面和数据平面分离。控制平面主要包括session、Flow和信令的管理，运行在User Space和Slow Path环境中。数据平面由一精简的指令集组成，运行在FastPath环境中，专门负责网络报文的处理和转发。Application、SlowPath和FastPath三者之间通过MCC（Multi-core Communication）通信，MCC同时支持本地和远程通信。

（2）通过在FastPath和SlowPath引入ENS Framework，网络协议栈的功能得以以模块的方式互联，模块可以静态或动态的插拔，通过配置平面组合成不同的网络协议栈，以适应不同网络设备对协议栈的需求。

（3）Application可以运行在本地，也可以是远程的信令模块，并可单独开发和部署。从而降低系统的耦合性，提高整体的可靠性和扩展性。用户或第三方的Application可以无缝的和FastGate框架进行集成。

（4）FastPath运行在独立、高效的多核执行环境中，对网络报文的处理要求做到Simple and Stupid, 使其得以充分发挥多核并行处理的性能优势。为此，FastPath中的功能模块都采用高效的数据结构和算法，并针对多核并行处理进行优化。

（5）SlowPath由优化的Kernel协议栈和ENS Framework组成，主要负责IP协议栈的Session、Flow等的管理，并和FastPath进行数据同步。

ENS（Extensible/Efficient Network Stack Framework）负责构建网络协议栈。ENS中的各个功能模块之间是相互独立和透明的，模块之间通过hook的方式互连。模块可以静态或动态的添加和删除，这使得协议栈的扩展非常灵活，而又无需担心性能问题。由于ENS Framework应用在整个协议栈，使得用户不论是在L2、L3，还是L7都可以很容易的扩展自身的业务，从而使得整个系统兼具软件的灵活性和硬件的高性能。

以LTE EPC中SGW和PGW为例，用户的开发也分为控制平面和数据平面。控制平面即符合3GPP规范的SGW和PGW的协议部分，开发完成后，可以部署在FastGate所在的板卡，也可以根据需要部署在独立的板卡上。数据平面即SGW&PGW的报文处理部分，开发完成后作为一个功能模块插入到Fast Path的ENS Framework中，就形成了SGW&PGW的网络协议栈。

关于系统的性能，下面给出基于Cavium cn5850（12 Cores, 600Mhz）的IPv4 Unicast Forwarding (8 cores for fastpath)的性能测试数据：

Fib Number 28,892
Memory Occupied(MB): 3.44
Measured in PPS 4,627,408
Measured in Mbps 4,000 (limited by I/O throughput of ispan9210)
Measured in Latercy(μs) 5 ~ 10

目前FastGate已经在包括ATCA 和Micro-TCA多个平台上应用，所涉及的项目包括Wi-Fi AC, ASN GW, Femto SeGW, LTE EPC PGW, LTE EPC SGW等。期望弯曲的朋友和专家能不吝赐教，批评指正。 （fastgateteam@gmail.com）

(4个打分， 平均：5.00 / 5)

工具箱
本文链接 | | 打印此页 | 49条用户评论 »

雁过留声

“多核处理器下的快速包处理软件架构FastGate”有49个回复

  1. 老韩 于 2012-08-06 6:21 下午

    fastgate是办事处设在上海那家么？

  2. lyn 于 2012-08-06 6:24 下午

    写得不错啊

  3. 新手0 于 2012-08-06 6:39 下午

    问个特小白的问题：session和flow的区别是什么？一个双向一个单向？

  4. fastgateteam 于 2012-08-06 7:02 下午

    我们香港本地研发机构， 在上海没有办事处

  5. 弯曲老友 于 2012-08-06 7:21 下午

    我的理解是flow通常指网络层，session通常是指应用层或传输层的概念。

  6. 陈怀临 于 2012-08-06 7:56 下午

    不错。slow path和fast path分的比较清楚。BTW，楞要和OpenFlow扯在一起，uuuum，略微blahblah了一点。

  7. beans 于 2012-08-06 8:07 下午

    这个架构,还是比较传统的阿,若是现在重头做个架构,恐怕这种已经不是首选了.

  8. Today 于 2012-08-06 9:04 下午

    “beans 于 2012-08-06 8:07 下午
    这个架构,还是比较传统的阿,若是现在重头做个架构,恐怕这种已经不是首选了.”

    请问首选的架构是什么？

  9. 沙加 于 2012-08-07 1:25 上午

    转发架构很难做成通用，基本到具体产品那里都得重新定制一部分

  10. yfydz 于 2012-08-07 2:08 上午

    用hook方式实现协议栈还是有性能问题的，netfilter就是典型的例子，节点多了需要好好优化的

  11. freenet2008 于 2012-08-07 3:52 上午

    这个平台和6wind的太像了，有没有PK的报告啊

  12. 抓狂 于 2012-08-07 7:10 上午

    根本就是一个宣传稿，无新意可言。
    另外，4Gbps，性能低了点吧。

  13. Xin Qian 于 2012-08-07 12:28 下午

    这个思路还是控制平面和转发平面分离的思路，如果要用在SGW/PGW需要完成DPI和其他计算intensive的任务，我觉得这种层级的路由最好能云化得到可伸缩的计算资源
    =============================
    以LTE EPC中SGW和PGW为例，用户的开发也分为控制平面和数据平面。控制平面即符合3GPP规范的SGW和PGW的协议部分，开发完成后，可以部署在FastGate所在的板卡，也可以根据需要部署在独立的板卡上。数据平面即SGW&PGW的报文处理部分，开发完成后作为一个功能模块插入到Fast Path的ENS Framework中，就形成了SGW&PGW的网络协议栈。

  14. Lin Han 于 2012-08-07 2:40 下午

    有点SDN/OF的味道，关键看控制软件有多牛.SDN作出来，其他的都是浮云了。

  15. YY 于 2012-08-07 5:41 下午

    挺好的介绍

  16. alex 于 2012-08-07 6:24 下午

    4Gbps确实有点儿低，用FPGA加速很容易做到10Gbps以上。

  17. npxe 于 2012-08-07 8:01 下午

    敢问4.6Mpps用了几个核？
    IPv4转发查了几个表？

  18. npxe 于 2012-08-07 8:09 下午

    第一次看见香港有研发,以后是否跳槽可以考虑一下香港

  19. fastgateteam 于 2012-08-07 8:12 下午

    系统的灵活性和性能会相互制约，要得到很好的灵活性、扩展性，牺牲一些性能是不可避免的，系统的设计的过程就是权衡和取舍这些矛盾的过程。

    控制平面和转发平面的分离机制由来已久，不同设计的差异在于分离机制应用的范畴和分离的深度、广度。FastGate通过对两者的充分分离，形成灵活的、软件化的控制平面和精简的、硬件化的转发平面，这就为整个系统的扩展提供了很好的架构基础。同时，两者之间的消息传递和数据同步采用统一的MCC机制，使得控制平面的功能模块可以分布式部署，进一步提高了系统的可扩展性。

    整个网络协议栈的内容非常丰富，而具体到某个产品，它所包含的功能集又往往是有限的。这就使得以hook的方式互联的协议栈在性能上的损失是完全可控的，可它带来的却是非常灵活的扩展性，使得针对不同产品的功能定制，所做的仅仅是差异业务功能模块的添加、删除和相应配置文件的修改。在实际的性能测试表明，hook机制带来的性能损失是在10%左右，是可以接受的。

    BTW，前文所述的性能测试是基于板卡ispan9210，该板卡的I/O吞吐最大值是4Gbps，所以，对于IPv4 Unicast Forwarding的性能请参看PPS.

  20. fastgateteam 于 2012-08-07 8:23 下午

    前文所述的性能测试是基于板卡ispan9210，该板卡的I/O吞吐最大值是4Gbps，所以，对于IPv4 Unicast Forwarding的性能请参看PPS.

  21. fastgateteam 于 2012-08-07 8:25 下午

    8个core用于转发平面

  22. Feng 于 2012-08-07 11:51 下午

    已经有做平台的了。以前和朋友聊过，可以创业做一个平台。因为大部分设备厂商的底层功能基本上都是相似的。何必重复造轮子呢

  23. ovid 于 2012-08-08 12:57 上午

    不错的东东，继续加油！

  24. freenet2008 于 2012-08-08 1:24 上午

    能介绍下你们的成功案例吗？或者现在的客户？

  25. balabala 于 2012-08-08 6:06 上午

    挺好的介绍。 里面纳入了很多的概念， 控制数据面分离（首席说是SDN， 偶不甚赞同， 控制数据分离一直都有， 上升到SDN的程度， 那要开分离的程度， controller 的集中程度）， 协议模块的可扩展性等等。 但是你们的目标客户是什么呢？ 如果出售的是一个架构的话，未必会有市场。 每个公司都会有自己的一套东西。 稍微大一点的router 基本上以NP的天下。 建议跟处理器厂家合作，做一些定制， 捆绑销售~ Cavium， FSL， 或者Netlogic， 傍上一家即可。

  26. abel 于 2012-08-08 8:06 上午

    ===胡侃sdn和openflow===

    sdn是很笼统的概念.我写一个shell,输入通用格式的配置文件,映射到不同厂商的设备,就得到不同的配置文件,只要各厂商的设备能实现对数据流的识别\标记\处理,那么这也叫sdn.
    在软硬件不统一的前提下做sdn我觉得更有现实.

    因为基于利益的原因,各厂商不可能真心实意地把负责转发的硬件都统一成一个标准(比如之前有文章说C和AL的处理器思路就完全不同).网络世界的x86体系都没有,那么软件的统一,哪怕是形式上的统一,就是一件很难的事情.
    我不能想象,各厂商使用各自的处理器,但操作系统还按照统一的规范来写,都支持sdn,甚至于都支持openflow.有类似的先例,一个操作系统支持多种cpu,比如debian支持mips和x86,比如android支持arm和x86,比如win8支持x86和arm.但感觉总怪怪的…

    最后补充一句,各大厂商网络设备之间的互操作性是噩梦.成本和市场占有率双高的网络厂商(比如C)有充分的理由和动力确保设备互操作性一桶糨糊.

    C连e协议都搞成私有的,养着rj牵制h,试问c为什么不像当初对待h那样对待rj,大打专利战,灭掉rj呢?可见很多问题根本不是技术问题,就像这键盘的破烂排序一样,改起来成本颇高,主要是现有玩家的利益问题.

    基于对C的认识,我斗胆猜测,C就算说要支持openflow,也一定会往里加一堆乱七八糟的私有玩意儿,最后搞成cxxxxflow.不信等着瞧.
    哪有革命把自己的命革掉的.

  27. 理客 于 2012-08-08 5:08 下午

    所以体制内的革新比体制外的推翻更难，把OF/SDN寄托在C/J身上是与虎谋皮，所以一定要有能独立支撑OF/SDN的新人王出来，用伟大领袖斗争的一生总结的斗争哲学：以斗争争和平和平存，以妥协求和平和平亡。江湖里ZZ利益的斗争不是以个人意志为转移的，这个世界，不是单纯的善意就能结出正果。

  28. 理客 于 2012-08-08 5:12 下午

    如果能紧紧兼容OF/SDN，前途无量，否则只是打拼在小有市场。

  29. 好奇者 于 2012-08-08 7:08 下午

    to理客：请教这里说的控制平面、转发平面的分离和OF/SDN的区别在哪里？会被OF/SDN取代？

  30. fastgateteam 于 2012-08-08 8:03 下午

    首先，再去感谢陈首席和弯曲朋友们给力的支持和精彩的评论。由于业务的拓展，FastGate团队诚邀在Linux Kernel和Networking Stack方面有开发经验的工程师加盟。工作地点在香港，环境一流，有意者可向fastgateteam@gmail.com递交简历，做进一步交流。

  31. 低调再低调 于 2012-08-08 11:01 下午

    这个框架看着有点netfilter的味道，但是在转发层面搞框架缺乏灵活度，是不是用了这个框架大家搞出来的东西都可以批量复制了，另外这个框架说是不依赖硬件平台，不知道是怎么做到的，毕竟不同CPU的核间通信机制就不同，像RMI的和X86的，另外这个框架底层的OS是什么？开源linux？怎么保证厂家对底层OS的可移植性，还是已经提供了对不同OS的封装

  32. multithread 于 2012-08-08 11:22 下午

    贴错了，应该是这里的。

    最好在性能上把6wind打倒后，再考虑商业上的应用。

    随便提一下，6wind最近爆了一个17Gbps的TCP处理速度，当然是大包的了 ：-）

  33. 路人甲 于 2012-08-08 11:57 下午

    按照cn5850这儿CPU的性能来算，软件足够强大话，做到6Gbps，是可以实现的吧？

  34. balabala 于 2012-08-09 12:04 上午

    to 29:

    我个人的理解是控制面数据面分离跟SDN 本质上是一致的， 归根结底是度的区别。 SDN 是把很多roter 获知switch的控制面集中在一起， 是个大范围的分离。 理解也许不对， 请主席指教~
    to 32:
    没有用过cavium的东西， 倒是用过FSL的单核CPU做过转发， 1.7G， baremetal OS， 可以做到单向700K， 双向1.4M pps。

  35. fastgateteam 于 2012-08-09 12:57 上午

    FastGate目前和业界多家通讯产品厂商合作，有关这方面进一步的咨询，请通过邮箱fastgateteam@gmail.com直接和公司联系，会有专人负责。谢谢。

  36. 理客 于 2012-08-09 5:32 下午

    to 29：区别是你要自己的系统接口，还是follow下一代主流标准接口？being or not being，自己选择，自己负责，成败有人看

  37. 吴辉 于 2012-08-22 6:15 下午

    控制与转发分离，慢路径与快路径分离，这是基本共识。　　　

    如果说5850只做到4.6Mpps的v4单播转发，你们团队还有很长的路要走。

  38. softarts 于 2012-08-23 6:57 上午

    框架不是重点吧,intel dpdk+6wind,或者dpdk+自己的DPI engine，都可以，框架的优势？

  39. grace 于 2012-08-23 7:15 上午

    测试一下，是否可以发表评论。

  40. multithread 于 2012-08-23 12:00 下午

    According to the Linley group:

    System designers’ thirst for multicore processors that excel at data-plane tasks has been mostly quenched. The business still has plenty of room to expand, but the years of greatest growth have passed.

    For example, Cavium’s semiconductor revenue (a proxy for the multicore market) fell 15% in 1H12 compared with 1H11.

  41. lucia 于 2012-08-23 7:41 下午

    猜大家都在看着intel持币观望中。呵呵

  42. Alex 于 2012-08-23 7:47 下午

    pps是不错。DPI呢？难道就靠剩下的4个core？不要告诉我可以上协处理。软件厂商只能无助的等待intel告诉大家一个方案。

    btw，上面还有个alex哦！

  43. zgh 于 2012-10-23 4:43 上午

    和6wind有啥区别？

  44. 瑞雪祥云 于 2012-11-12 6:25 下午

    看着好像我们用的BROADLIGHT 的GPON ONT套片.确实很像。

  45. 瑞雪祥云 于 2012-11-12 6:33 下午

    linux + mips ||| slow path
    —————-

    NPs + MAC chip ||| fast path
    —————-

    修改netfilter 内核部分，linux上conntrack 建立后，同步下发到NP处理，成为fast path。 同步iptables 到NP称为ACL或者rule。当然功能上比交换芯片的rule差些。
    用户态做一些NTP FTP 之类的开发。

    不过好像同步比较烦，小问题多，硬表上很难做到跟LINUX一样强大，要搞很多适配，容易出问题。

  46. 香港应科院多核软件平台团队诚聘 : 弯曲评论 于 2012-11-14 6:27 上午

    [...] More information about FastGate [...]

  47. 孤魂野鬼 于 2012-11-15 1:12 上午

    4Mpps的性能还是比较低的；基于多核的应用加速，前景不是那么明朗吧，多核计算能力提高了，但是访存才是制约性能的最终瓶颈。有限的LLC，在应用数据集较大时，LLC竞争更激烈；PCIe I/O带宽尽管高，但是延迟如何隐藏，优化LLC竞争带来的延迟都很重要；如何利用应用数据集的局部性，对高频访问数据进行y存储优化，规则访问数据进行预取控制，都十分影响最终应用的性能。目前很多机遇x86的I/O优化研究，做的都很极端，也很极致，最终选择什么包处理应用，什么应用能很好利用上述特性，才是最重要的。

  48. rinehart 于 2012-11-17 7:25 上午

    想回南方发展，做过WLAN开发。
    还招人么？

  49. jiay 于 2013-06-19 12:08 上午

    FastPath中的功能模块都采用高效的数据结构和算法，并针对多核并行处理进行优化。

    能不能具体点？