SDN — OpenvSwitch 软硬件融合加速方案

梦里梦外; 2023-10-09 21:23 72阅读 0赞

## 目录 ##

#### 文章目录 ####

*  目录
 *  OVS-DPDK
 *  OVS Hardware Offload
 *  OVS-DPDK Hardware Offload

## OVS-DPDK ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70]

上图中的深蓝色模块是 OVS-DPDK 基于 DPDK 开发库引入的新模块。

*  **ofproto-dpif**：实现了 ofproto 模块的 API，用于操作 dpif 模块。
 *  **dpif-netdev**：在 Userspace 中实现的 Fast Datapath，实现了 dpif 模块的 API，用于操作 netdev 通用设备。
 *  **netdev-dpdk**：实现了 netdev 模块 API，提供了多种 DPDK-based 的 Ports 类型，如下：
    
     *  **vHost**：使用 DPDK librte\_vhost 库实现的 vhost-user Port 类型，作为 VirtIO Networking 的 Userspace 加速 Backend。
     *  **Physical ports**：使用 VFIO / IGB\_UIO Framework 实现的 PMD Port 类型。
     *  **dpdkr**：使用 DPDK librte\_ring 库实现的 dpdk-ring Port 类型，和 VM 之间通过 IVSHMEM（Inter-VM Shared Memory）完成零拷贝通信。

在生产环节中最常见的 netdev-dpdk Port 还是 vHost 类型，带来了更高的转发性能，但也存在新的问题。

1.  大多数服务器 CPU 都是 NUMA 架构的，而 PCIe NIC 只与其中的一个 NUMA Node 具有 Local Memory 亲和性，但 VM 可能运行在任何 NUMA Node 上。所以 OVS-DPDK 不可避免的会进行跨 NUMA Node 转发流量。所以对于性能有高要求的 VM 应该还要考虑强制执行 PCIe NUMA 亲和性。
2.  当 VMM 使用 VirtIO Networking 虚拟网卡设备时，VM virtio-driver 和 OVS-DPDK vhost-user Port 之间通过共享内存来构建 Virtqueues，并且 VM 初始化的 Rx/Tx Queues 数量通常和 vCPU 个数相同，才能保证每一个 vCPU 都通过共享内存收发包。这会导致不同规格的 VM 之间会在 CPU 和 Memory 都超分的环境中互相竞争 pCPU 和 pMemory 资源。无法保障租户带宽隔离。所以对于性能有高要求的 VM 应该考虑关闭 CPU 超分。

![在这里插入图片描述][6da7c15383d84372b53ea2b0a35a021c.png]

另外，在实际的测试中发现，在同主机的东西向流量场景中（VM-2-VM），OVS-DPDK 的性能会优于 SR-IOV。因为 OVS-DPDK 在同一主机中拥有更短的流量路径（均在 Userspace），并且不占用物理网卡资源。而在跨主机的东西向流量和南北向流量场景中，则是 SR-IOV 的性能更优。

## OVS Hardware Offload ##

2018 年，OpenvSwitch 发布了基于 TC Flower 的 Hardware offload 功能，支持将 Datapath 卸载到 SmartNIC 上。

如下图所示，在 OvS Hardware offload 架构中存在了 4 个 Datapath。

1.  **User Datapath**：ovs-vswitchd Flow Path
2.  **Kernel Datapath**：openvswitch.ko Fast Path
3.  **Kernel TC Datapath**：作为 Offload TC Datapath 在 Kernel 中的挂载点
4.  **Offload TC Datapath**：SmartNIC Fast Path

在 SmartNIC 开启了 OVS Hardware Offload 功能之后，在启动 ovs-vswitchd 时，就会通过 TC Flower 向 Offload TC Datapath 下发一条 Default Flow Rule，将所有在 Offload TC Datapath 种匹配失败的数据包都传入 Kernel Datapath。如果在 Kernel Datapath 中还是匹配失败，那么就按照原来的方式，将数据包上传到 User Datapath。然后在逐级的将 Flow Entries 下发到下层 Datapath。

另外，ovs-vswitchd 还能够根据 Flow Entry 的 Hardware Offload Flag 判断应该将其下发到 Kernel Datapath 还是 Offload TC Datapath。

![在这里插入图片描述][5c95e25db19f41ce926b98986811a962.png]

OVS Hardware Offload 带来的显着好处就是结合了软件的灵活性和硬件的高性能。结合 SmartNIC 的 SR-IOV 特性，可以通过 VF 直通的方式接入到 VM。

![在这里插入图片描述][99178ce4562f4a5789bf7178074a4a47.png]

## OVS-DPDK Hardware Offload ##

DPDK Hardware Offload 基于 DPDK rte\_flow 库来实现，支持将 OVS-DPDK Flow Rule 卸载到 SmartNIC 上。

一条 RTE\_FLOW 由以下 3 个部分组成：

1.  **Attributes**：指定 Flow 本身的属性，包括：port、ingress/egress、group、priority、transfer 等。
2.  **Match**：指定 FLow 的匹配模式。
3.  **Action**：指定匹配成功以后执行的动作。

![在这里插入图片描述][fc095f389b2c4d998e87c83ac067241f.png]

在更新的 OvS-DPDK Hardware offload with vDPA Framework 中，OvS 的 Control Plane 部署在 DPU OS 中，而 Data Plane 则 Offload 到 HW 上，CP 和 DP 之间通过 DPDK 标准 rte\_flow 方式进行交互，以此实现了 OvS Full offload。

DP 卸载后，还可以把 VirtIO Networking Backend 一同卸载到 HW。通过 VirtIO vDPA Backend 将 VF 接入到 VM 或裸金属中的 virtio-net Front-end，数据的传递无需 CPU 的干预，实现更高的网络转发性能。

![在这里插入图片描述][ceeeda22e30941bd93633237555e2801.png]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020062313341373.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr,size_16,color_FFFFFF,t_70
[6da7c15383d84372b53ea2b0a35a021c.png]: https://img-blog.csdnimg.cn/6da7c15383d84372b53ea2b0a35a021c.png
[5c95e25db19f41ce926b98986811a962.png]: https://img-blog.csdnimg.cn/5c95e25db19f41ce926b98986811a962.png
[99178ce4562f4a5789bf7178074a4a47.png]: https://img-blog.csdnimg.cn/99178ce4562f4a5789bf7178074a4a47.png
[fc095f389b2c4d998e87c83ac067241f.png]: https://img-blog.csdnimg.cn/fc095f389b2c4d998e87c83ac067241f.png
[ceeeda22e30941bd93633237555e2801.png]: https://img-blog.csdnimg.cn/ceeeda22e30941bd93633237555e2801.png