开放网络设备关键使能技术

作者简介：老顽童 oldurchin2019@163.com

一、背景

网络设备（如交换机）一般由思科、华为、华三等网络设备商基于Broadcom、Intel、Marvell等网络芯片商的芯片方案进行研发测试并交付最终客户。过去相当长一段时间，芯片厂商为了保护自己的知识产权，通过SDK的形式开放操作芯片的API接口供网络设备商进行设备开发，且获得SDK需要和芯片厂商签署SLA、NDA等保密协议，某种程度上对网络设备商进行了“锁定”。网络设备商基于芯片厂家特有的SDK开发出的网络设备，传统linux的ip、ethtool、brctl等命令统统失效，留给用户的是专用的命令行或网络管理工具，这在某种程度上对网络设备的用户进行了“锁定”。

使用网络设备能像使用PC或服务器一样，选择A厂基于Intel处理器的硬件还是B厂基于AMD处理器的硬件，安装Windows或者Linux操作系统，决定权完全回归最终用户这一诉求从未变过，且随着网络设备白盒化理念的普及变得空前强烈；聚焦设备功能开发性能优化，而不是消耗相当一部分精力用来研究不同芯片厂家晦涩深奥的SDK及相关API，是每个网络设备开发者内心深处的渴望；熟悉特定芯片厂家SDK的人才相对普通开发人才属于小众群体，物以稀为贵，网络设备商希望缩小这类人才的需求，甚至完全用普通开发人才取代这类人才。

下面介绍两种有望解决上述问题的开源框架：Switch Abstraction Interface（SAI）和switchdev,并对两者从不同维度进行简要对比分析总结。

二、SAI

SAI是Open Compute Project (OCP)网络组的五大子项目之一，介绍SAI之前有必要先介绍一下OCP。

OCP将自己定位为“一个致力于重新设计硬件技术以有效地支持对计算基础架构不断增长的需求的协作社区”, 成立于10年前，当时的想法是设计世界上最节能的数据中心，如今，OCP包含了现代数据中心体系结构最关键方面的规范-服务器，存储，机架和电源，安全性，网络，硬件管理等。

OCP的网络组聚焦网络方面的研究，包括五个子项目：ONIE，ONL，SAI，SONiC和CBW。其中最关键的是SAI和SONiC（Software for Open Networking in the Cloud），因为几乎所有主流参芯片供应商或OEM / ODM厂商都至少参与了这些开放计划中的一项。

SAI接口采用标准C实现，定义了基于对象的通用CRUD API，用于交换芯片的配置和监视，对上层的NOS提供了统一的API，屏蔽了底层的硬件细节，API和属性命名方案都有统一且严格的规则。

采用SAI作为南向接口和交换芯片厂家的SDK进行适配对接，开发者可以快速平滑地支持多种交换芯片厂家方案的硬件平台，比如目前热度很高的开源网络操作系统SONIC，运行在Dell基于Broadcom的白盒硬件上和运行在Edgecore基于Barefoot的白盒硬件上，并不需要维护两套NOS代码，硬件平台差异的适配仅限于SAI接口的实现（分别采用Broadcom的SDK和Barefoot的SDK）,主流交换芯片供应商也在积极向社区贡献，丰富SAI接口对其芯片系列和型号的支持。

SAI作为南向接口简化了网络操作系统（如SONIC）对异厂商硬件平台适配工作的同时，也为同一个硬件平台支持多个NOS提供了便利。Delta的硬件安装SONIC/OPX/Dnos/ONL或者其他NOS,用户自己说了算。

和大家结合目前流行的开源网络操作系统SONIC对SAI进行一个直观的认识。如下图所示，SONiC有个包含SyncD进程的容器，该进程使用通用SAI接口来配置交换芯片。Redis数据库是SyncD和SONiC应用程序之间的唯一通信通道。Redis的ASIC DB包含根据应用程序生成的配置和运行时状态（路由，邻居MAC等）经由Orchagent进程转换的SAI格式的序列化字符串数据。SyncD从ASIC DB获取数据并调用SAI的相关API下发到交换芯片。可以看到SAI的出现成功地实现了控制平面的主要部分与ASIC驱动器层（供应商SDK ）的解耦。

SAI不仅对交换芯片的操作进行了成功的抽象，也逐渐成为了外部PHY芯片配置的通用接口。SAI的成功还体现在TIP(Telecom Infra Project )的TAI(Transponder Abstraction Interface),TAI定义中使用了相同的设计方法，这些定义采用了SAI中的许多术语。

三、Switchdev

上文介绍的SAI框架属于linux用户态实现方案，Linux 内核4.0以前，内核态并没有对硬件交换芯片的支持。bridge模块Linux 内核很早就支持，不过是一个软网桥，所有的交换都是通过 CPU 实现的，并没有实现对于真正硬件交换机的支持，对硬件交换芯片的通用接口抽象层面一直没有合理的解决方案。

Linux 4.0 引入了 switchdev 框架，全称是 Ethernet switch device driver model，它代表一类具有交换能力芯片的多网口设备的抽象，使内核将交换功能 offload 到硬件上成为可能。

Linux内核对普通网卡的每个网络接口用net_device结构体来表示，在switchdev框架中交换芯片的每个端口被抽象为一个网络接口，对应一个成员扩充了的net_device结构体。对net_device成员的扩充主要体现在switchdev_ops和offload_fwd_mark这两个成员，switchdev_ops用来实现不同厂家交换芯片的具体操作实现，offload_fwd_mark用来避免已经被offload的packet再次被forward。

Linux内核引入switchdev框架后屏蔽了硬件方案的差异，采用BIRD、FRR等主流开源项目的网络设备几乎不需要改动就可以享受通过switchdev进行硬件offload带来的性能提升。促使采用linux的网络交换设备朝着软硬解耦设备开放迈出了坚实的一步。客户可以轻松使用传统linux的ip、ethtool、brctl等命令管理不同白盒厂家网络设备的接口状态、MAC表项及IP地址等，彻底和抱着网络设备厂商厚厚的命令行手册废寝忘食的日子挥手作别。

四、分析总结

通过上文的分析，作为最终用户或网络设备开发者，无论是用户态的SAI抽象接口还是内核态的switchdev抽象接口，哪个最终成功都会受益。下面从八个维度对二者进行一个简要分析：

1. 抽象位置

SAI和switchdev都属于转发芯片的开源抽象框架，但两者的实现位置不同，SAI是在用户态的努力，switchdev是内核态的尝试。

2. 硬件对象表示

抽象框架一个很重要的工作就是对转发芯片的硬件对象（资源）进行软件抽象，以对上层的NOS提供统一的硬件资源视图，对底层硬件资源的操作提供实现框架。举个栗子：采用SAI接口的SONIC对交换芯片接口的抽像采用的是用户态redis数据库中的PORT_TABLE或INTF_TABLE，而switchdev则用内核态的net_device结构体。

3. 操作硬件对象是否需要定制化工具（命令）

还是用对接口的操作来举栗子，采用用户态抽象方案的SONIC一般会用show interface xxx，OVS一般会用ovs-vsctl list-ifaces，而采用内核态的switchdev抽象，一般继续用ip link命令就能达到同样的效果。

4. 传统linux工具（命令）是否可用

这里传统linux工具（命令）更多是指网络设备相关的命令，比如ip、ethtool、brctl等。采用switchdev框架的方案原生支持这些命令，可放心使用；而借助SAI框架的方案就得视情况而定了，大概率得学习一些非传统linux命令，ovs-vsctl add-br br0不少读者应该还有印象。

5. 是否接受非源码（二进制库）驱动

因为SAI在用户态搞事情，好多事情“好商量”，灵活性比较高，通过自家SDK的二进制库来实现SAI接口的芯片厂商也不少见；Linux kernel就是另一种风景了，毕竟内核里的代码权限很高，天知道芯片厂家的二进制sdk里会不会干什么“出格”的事情。

6. 驱动源码upstream是否必须

如5中的分析，采用switchdev框架的实现方案，驱动程序源码方式upstream是必须的，除非芯片厂商不打算跟着linux kernel主线版本混，抑或是另起炉灶自己维护一个打了很多补丁的主线版本，其实很多芯片厂家确实这么干。用户态的SAI框架方案这方面相对温和，二进制库方式不会不接受，有情怀有格局的厂家要提交源码实现，也绝不会拦着。

7. 挂靠的组织

SAI项目归属于OCP，关于OCP的介绍前文有述；switchdev项目归属于linux内核社区，更准确一些应该是linux基金会。

8. 开源license

开源license方面，SAI选择了Apache v2，switchdev却和GPL在一起了。

SAI和switchdev开放解耦的目标是一致的，只是达成目标的方式有所不同：一个选择了用户空间，一个选择了内核空间。为了同一个目标而在用户态和内核态分别努力的案例并不少见，DPDK与XDP就是一个很好的例子。DPDK和XDP大多数读者应该很熟悉，针对二者进行用户空间和内核空间实现方案优劣势的分析和辩论也很多，可以类比着看SAI和switchdev方案的优劣势。

目前SAI较之switchdev在芯片厂家支持数量方面是胜出的，如前文所述主流的芯片厂家几乎都对SAI进行了支持，而switchdev的支持者主要是Mellanox的10/25/40/50/100G 系列芯片及Broadcom的接入交换机、家庭路由器等消费级芯片。这可能和OCP与linux社区在生态建设方面的力度和能力等非技术类原因有关，从技术角度看，switchdev要求交换芯片厂家实现switchdev_ops的源码upstream到linux主线以便随着内核的版本迭代而持续演进，而SAI相对温和一些，允许交换芯片厂家以SDK二进制库文件的形式实现SAI接口。

总结一下，SAI和switchdev同属于网络交换类设备的解耦框架。解耦力度SAI较之switchdev温和一些，芯片厂商容易采纳。易用性、设备轻量化方面switchdev较之SAI更优雅一些，开放网络设备用户容易青睐。二者谁能走的更远？答案交给时间来揭晓吧！