峰会回顾 | 可编程交换机：从芯片定义网络到软件定义芯片

前言

      11月19日第十一届网络平台部技术峰会在深圳圆满落幕。本次峰会围绕硬件研发、硬件加速、网络产品、网络运营四大领域，深度全面地展示了网络平台部不断精进的研发能力及探索成果。下面让我们共同回顾本次峰会中由软件研发专家——文权呈现的《可编程交换机:芯片定义网络-->软件定义芯片》的精彩内容。

开场

      今天给大家的分享主要分成三个部分：第一部分是讲芯片定义网络的历史，在网络发展这近20年其实一直都是被芯片牵引着，我们能能打造什么样的网络，不是由业务需求决定的，而是芯片决定的，是先有什么样的芯片，我们才能打造什么样的网络。在最近三、五年，我们的话语权增强了，但是这种模式并没有发生根本性的改变。第二部分的分享是我们现在正在做的事：开始让业务来去定义芯片，我们业务需要什么，就做什么样逻辑的芯片。最后部分给大家分享一下我们现在正在大力推进的可编程交换机平台。

芯片定义网络

      下图是网络领域的处理器的性能和灵活性示意图。从左到右我们可以看到它的性能是越来越强，但灵活性越来越弱，比如说当前最强的通用处理器—CPU，能够处理的报文效率是100Gbps ~ 200Gbps左右，但是一个专用的网络交换芯片的处理能力是25.6Tbps，而且51.2T芯片也快出来了，大家可以算一下这中间性能差距有多大吗？—整整1000倍的差距!

      上午的分享嘉宾也说到“我们的网络对高性能、大带宽、低延时永远有无尽的渴求！”。所以我们就一直在依赖着这种专用芯片，这就支撑了它一直掌控着我们的网络。自从当初我们加入世界互联网之后，我们也就必须遵从之前他们定义的各种网络标准，进而用他们定义的专用芯片，然后就造成了持续到今天的“芯片定义网络”的局面。所以回顾我们的网络发展的历史，其实是一部“看交换机芯片的米下锅”的历史。但是人类那种对美好事物的追求一直都没有停滞过，虽然专用芯片能提供让我欲罢不能的带宽、低延时需求，但是我还是要追求有灵活性—SDN，这个已经是个老话题了，Nick教授提出来了也快有10年了，但 SDN只是对专用处理器操控的网络的的一个改良而已，就国内、外的案例来看，SDN控制交换机实际上都并不算成功。反而SDN做的比较好是控制服务器(OVS)，本质原因还是交换机被交换芯片控制着，加上商用NOS系统和控制器对接的各种问题……

软件定义芯片

       现在已经是2021年了对吧？我们是不是应该要“改变”一下呢？能否不再被这种芯片逻辑给控制了呢？而且我们的网络规模也早已突破100万台服务器，20+万台交换机了？我们如果再不转变，是不是也越来越无法满足我们业务的需求？所以我们已经在尝试通过软件定义芯片，这是怎么做到的呢？要做到这一步，我们有必要知己知彼，我们先把交换芯片打开看一下，交换芯片里面到底有什么？如下图示：

      交换芯片其实它主要有几个部件：一个是高速SERDES，就是我们通常说的什么56G的PAM4, 25G的NRZ，它是干什么的呢？它主要实现了把数字信号转换成电信号，做串并转换，然后它再通过光模块转变成光传输出去。大家可以看到 SERDES实际上是一对差分对，就是在上图的最左边；然后是MAC，其实它就是把一个刚才说的数字信号转换为报文流。经过了MAC之后，我们才能看到完整的报文(之前是比特流)；接下来是表项，芯片里面其实只有两种RAM，一种是SRAM，一种是TCAM。SRAM一般用于直接寻址的表和精确匹配查找表（EM）；然后TCAM是什么？TCAM其实是增强型CAM，而CAM就是基于内容的快速匹配查找的一种硬件存储。如果作为软件的同学可以有一个很好的比喻，你可以把它是当做是一张哈希表，但是它是用硬件实现的。那TCAM是什么？我们通常熟知的门电路只有‘0’和‘1’两个状态，而TCAM是有第三个状态的“do not care”，的意思就是你可以忽略它的值，它需要我们的把所有存储器的门电路设计成是拥有第三态，这会极大的增加它的功耗和成本；还有一部分叫逻辑，在x86上就是我们写的CODE，逻辑实现报文从端口进来之后，去查找什么表，然后做什么样的修改，然后怎么转发出去，传统交换机芯片这部分在流片后就是固定不可修改的了；最后一部分是拥塞管理(TM和MMU)因为和可编程关系不大此处不再详述。

      而交换芯片本质上就是在一个芯片内实现把这种高速SERDES加上表项（TCAM、SRAM）再加上查询、转发、封装的逻辑，再加上MAC、MMU等几个关键部件组成、封装在一起，并且满足足够低的功耗、成本要求的产物。而且交换芯片也是我见过的封装的高速信号密度最高的单一芯片，而Serdes技术也是交换芯片最重要的最核心的技术之一。

      然后我们再看一下可编程芯片长成什么样子呢？可编程芯片它到底是对什么进行编程？我们刚才讲到这5个关键部分，其中有一部分叫逻辑，可编程的概念其实就是针对逻辑的，我们可以对照着这两幅图看一下，可编程芯片实际就是把分析、查表、转发、封装的这些逻辑都做成空白的，就是Parser、Match-action，就是你想怎么转发逻辑你自己来填：

      而固定流水线的芯片是把这些东西都已经填好了，比如说你要先做二层转发，二层转发之后做三层转发，然后做VXLAN或是GRE以及做ACL等等，显然可编程芯片会更灵活一点。所以我们可以对PARSER、MAU编程，来实现一个灵活转发的目的。然后我们再来看一下这个门槛是不是非常高？“我要对芯片进行编程”，乍一听可能就觉得这肯定是一个跟芯片底层技术关联很深的东西，要很多年的专业知识的才能做的一个事情。但其实并不是这样，接下来我们可以看一下怎么样去做可编程开发，其实我们只要会写现在最流行的P4 CODE就可以了，当然现在也已经不止一种编程语言了，不过P4是当前最流行的，下面我展示了一个P4代码片段和开发模型，相信只要是程序员的，大部分人应该都能看得懂吧？

代码解读

      如果报文协议是以太网，我就做MAC查表转发，如果它miss了，我就做 “未知名报文转发”。虽然这只是一个代码片段，但即使做一个网关设备的可编程，它的代码量也就在几K左右，不会很多，代码的形式就是这个样子，很类似于C，然后我们用芯片厂商提供的的编译器进行编译，编译之后它会生成两两个大组件，一个是自动生成的C代码(低层次的驱动)，一个是固件以及表项配置文件。

      这两部分作用是什么呢？我们先讲一下Micro code和配置文件：

      配置文件：通常可编程芯片提供的只有一整块SRAM、TCAM，我们要把它分割成几十张表， 配置文件就是告诉芯片怎么样划分，把这些表都定义好，每张表占哪一块资源。

    Microcode：刚才说的这个PARSER、MAU编码最后编译成Microcode。它控制芯片进行报文解析，查表，按照表项内容进行报文转发/丢弃/镜像，封装等操作。

      编译器还会根据你的code定义去生成你的驱动代码(C code)，当然这是一个很底层的驱动（Low-Level-Driver）。然后在我们通常说的最小的系统还有一个控制平面，由它来调用我们实现各种网络转发模型。当然在它调用Low-Level-Driver之前，我们通常都会在之上再封装一个面向功能的驱动层(因为底层提供的 API代码是不是很友好)。

总结

芯片的可编程技术本身并不是一个技术门槛很高的东西，网络的核心技术实际还是掌握在芯片其它部分，例如Serdes技术、芯片封装，编译器(实际这个很关键，它实现了我们可以用高级语言来做芯片逻辑编程)等。但好歹我们开始掌握了芯片的逻辑部分，也算是一个好的开端。

      既然可编程芯片既有专用芯片的优点，比如说高性能、大带宽、低延时，又能灵活的对它编程，你想让它转发什么报文，它就转发什么报文，那为什么迄今为止，所有用到交换芯片的地方并没有全部替换为可编程芯片呢？相反，可编程芯片每年在全球的线上使用量还非常少。原因其实我刚才也说到过，交换芯片是有很高技术壁垒的(高速SERDES、MAC、TCAM/SRAM、高精度制程，封装技术等)，如果我们对转发逻辑没有超出RFC标准的定义，用可编程芯片能给我们带来什么样的价值呢？另外还有一个误区就是：我用了可编程芯片是不是就能像X86等通用处理器一样，想让它做什么他就做什么呢？其实也不是这样的，我后面会有一个例子来介绍。

      接下来我用一个“大报文overlay封装分片”的案例说明可编程芯片使用限制，如下图所示：

图表 1   报文分片示意图

图表 2    报文分片CODE片段 

      大家可以想一下，如果用Python、C++或者Java写一个报文分片，它应该什么样子的？先把一个SKB拷贝成两份，然后做一个截包，编辑包头丢出去就可以了，但是在专用芯片里面它不是这样的，原始报文要通过专门的拷贝(RPE)模块对它进行拷贝，拷贝出来一个镜像报文，然后我们还要把镜像报文回环(送回芯片的流水线初始转发逻辑处)，让原始报文继续走截断、转发等逻辑。这本质上还是专用芯片支持的处理逻辑是有限的，而且只能流水线的方式串行处理(不能一个报文处理一半停下来去处理另外一个报文，条件满足了再处理原来报文)，因此我们只能将镜像的报文通过回环的方式处理(回环是会占带宽的，而且还要占逻辑单元)。

      上面第二幅图是TD4的NPL代码片段，其实它就是在报文处理逻辑判断一下是不是一个“分片镜像”报文，是的话就对它进行进行忽略前36B的IP-payload处理(原始报文截断、丢弃了IP-payload的36B之后的数据) ，值得一提的是这个忽略字节数的能力也是有限制的(受报文最大解析长度影响)，因此分片的两个报文大小是非常不对称的。由此可见可编程芯片实际能支持编程逻辑也是非常有限的，很多从X86开发转过来的同学可能起初会有很大的不适应，需要经过一段时间对专用芯片流水线逻辑的深入的理解才能避免踩很多的“坑“，因此我们第一时间要摒弃的就是“将X86网关上的逻辑照搬到可编程芯片上来”的想法。另外可编程芯片本质上还是“专用芯片”，还存在资源不足及其它方面的限制，例如不支持循环等不可确定的逻辑，哈希也是有最大确定的碰撞次数。还有它的对报文的解析深度也是有限的，比如说它解析最大长度大约为200B左右，也不支持变长的报文头(因此对IP option选项支持很乏力)，这些是专用芯片的硬伤没办法解决的。

可编程软、硬件平台

      纵观业界的可编程交换机，可以看到一个很有意思的地方：通常会分散在各个业务部门独自开发软、硬件产品。通常存在如下几类问题： 

硬件资源方面

• 分散在各个业务，需求量少，不受芯片上游重视，硬件供应支持不足，量少但价格贵；

• 硬件无法定制（如高性能CPU通路/FPGA）；

• 上游芯片迭代慢，芯片核心技术缺失；

• 缺少硬件平台化考虑，缺少芯片层面的备份考虑；

软件OS系统方面

• 各业务使用不同集成OS方案，通用组件重复开发，如Underlay基础（ BGP协议等），基础运维、监控、管理工具；

• 基础OS系统、驱动依赖供应商提供，OS问题及新需求处理时效慢(且公司层面没有有效的积累)；不同供应商需要业务重复适配；

• 各厂商测试规范不一，沟通成本高，引入的流程长；

运营管理方面

• 预算、采购、设备录入、建设（基础配置、连接状态检查）、运维（隔离、监控、日志、故障处理、搬迁）等流程繁杂、冗长；

• 服务器 or 交换机模式运维都存在适配性难题；

业务烟囱问题

      业务组件重复开发，VXLAN，TGRE，NAT，IPSEC/MACSEC等。

基于以上难题，我们同各业务团队深入分析，并最终达成如下一致的软、硬件平台方案：

      如上图所示，在我们的硬件平台上既支持了业界通用的P4(Tofino芯片)产品，也支持了商用主流的TD4芯片(NPL)，以及最近一年多来方兴未艾的SiliconOne芯片(P4平台)。同时FPGA、高性能CPU等关键组件均实现了模块化设计，可以按照业务需求按需配置，软件平台也完全屏蔽了不同芯片、硬件配置带来的差异，给业务提供统一的OS服务接口，让业务能够更集中精力在业务本身、以及运维、监控特性的开发。同时我们还在内部拉通了业务代码的开源协同，按不同的网关类型最大限度的实现业务代码的协同、助力。

      网络未来将走向何方，其实我也看不确切，可编程芯片肯定是有需求的，而这背后的需求之源都是因为我们的网络、我们的云业务的变化，而我们做的这些事情都只是顺应这种“势”。

      最后，我借用一下最近各位大佬都热衷引用的一句话：“道阻且长，行则将至”！跟这张图也很配，我把个人的座右铭也贡献出来，把它对上了，虽然文字上不是很工整，但是意思很到位了！网络领域的封闭之路“道阻且长”，我们通过努力已经取得了阶段性胜利—行则将至，我们没有畏惧过去的困难，也必将不惧未来的艰险！谢谢大家！

欢迎关注公众帐号“鹅厂网事”，我们给你提供最新的行业动态信息、腾讯网络最接地气的干货分享。

注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利；

注2：本文图片部分来自互联网，如涉及相关版权问题，请联系sandyshuang@tencent.com；

/

关

注

我

们

/

/ 鹅厂网事/

分享鹅厂网络的那些事