DPU和CPU互联的接口之争：Virtio还是SR-IOV？

欢迎关注软硬件融合公众号：

---

编者按：

DPU和CPU通过PCIe高速连接，基于PCIe构建DPU和CPU之间的软硬件接口，如Virtio、NVMe、AWS的ENA/EFA等，以及各厂家自定义的基于SR-IOV接口。接口的性能、标准化和扩展性是整个系统成功的关键。

本文是NVIDIA关于此接口的白皮书，代表了NVIDIA的观点（不代表作者认同此观点），详细介绍了关于NVIDIA原生SR-IOV和标准Virtio在性能等方面的优劣势对比。

“软硬件融合”公众号持续学习和探讨各家方案，分析其优势和劣势。博采众家之长，给大家提供更多的灵感，希望能够帮助到大家定义和设计出更优的产品方案。

参考文献：

NVIDIA 白皮书：Comparison of OVS vRouter Acceleration Techniques: SR-IOV vs. VirtIO。

（标题）NVIDIA DPU白皮书：SR-IOV vs. VirtIO加速性能对比

1 背景

计算、网络和存储资源的虚拟化是云数据中心提供敏捷性、灵活性和可扩展性的关键能力。但这种灵活性通常以牺牲性能和效率为代价，因为传统的虚拟化是由消耗 CPU 资源的软件来完成的。特别是，当每个数据包都需要CPU处理时，I/O虚拟化会给处理带来沉重的负担。

存在三种不同的虚拟化方法：

• 仅软件

• 全硬件加速

• 混合方法

当前最好的例子是

• 虚拟I/O

• SR-IOV加速交换和数据包处理 (ASAP2)

• 结合了VirtIO和SR-IOV的混合

VirtIO是目前最常见的软件I/O虚拟化接口，它允许Guest设备驱动程序为块和网络设备提供一个通用的软件接口。这样做的好处是在VM中运行的应用程序不需要知道底层物理硬件。与传统的软件实现方式一样，VirtIO与SR-IOV相比有一些缺点：

• 与SR-IOV相比，性能和效率较差

• VirtIO硬件加速仅提供限制虚拟化功能的低级接口

• VirtIO硬件加速不会虚拟化所有功能，导致硬件依赖

SR-IOV 克服了大部分这些限制，但也有两个缺点：

• 并非所有操作系统都支持某些关键功能，例如VM迁移

• 必须编写VM和应用程序才能利用虚拟化加速

这些缺点都不是基于SR-IOV的硬件加速所固有的。例如，微软已经解决了Windows Server 操作系统的实时迁移问题，并允许使用完全加速的SR-IOV I/O进行VM迁移。允许VM迁移的软件正在开源社区中开发，并将很快在下游商业发行版中可用。同样，更高级别的功能正在针对服务质量（Linux tc_flower API）、网络（ESXi、Nuage、Contrail 等）、存储（NFV over Fabrics、RDMA）和安全性等功能进行标准化。越来越多的应用程序和虚拟化网络功能正在开发中，它们利用这些接口以及透明地使用硬件加速的选项。

因此，最终基于SR-IOV的硬件加速可提供更好的性能和效率，并提供比VirtIO更高级别的功能。但是，VirtIO的广泛采用和已经编写的现有应用程序基础应该准备好利用此接口。

此外，诸如将VirtIO加速卸载到硬件（硬件vDPA）等新发展通过将数据路径控制卸载到 SmartNIC 或数据处理单元 (DPU) 来提供额外的性能提升。这减轻了 VirtIO 的一些性能限制。

因此，目前没有一种适用于I/O虚拟化的“最佳”解决方案。解决该问题的另一种方法是采用混合方法，允许单个应用程序使用任一类型的接口。这允许以性能为中心的应用程序利用 SR-IOV加速，而数据密集程度较低的应用程序可以使用现有的仅软件VirtIO接口或硬件 vDPA。最终，具有支持更高级别功能和加速的API与低级别VirtIO或SR-IOV接口相结合的混合方法占了上风。随着最终混合模型的发展，网络解决方案可以独立并同时支持所有这些接口。

2 云数据中心的演进

云数据中心支持许多不同的应用程序，并非所有应用程序都需要高性能。服务器可以分为以下三个应用类别：

• 计算节点：作为弹性云服务的一部分，实例化运行来自客户的不同应用程序的虚拟机。

• 网络节点：运行网络功能，如负载均衡（基于 L4 或 L7）、IPS/防火墙、Anti-DDoS 等。

• 存储节点：运行分布式软件定义存储。

在所有的情况下，效率都很重要，即使对于本身不是高性能的应用程序，高性能网络一般也能提供间接的好处。例如，高性能网络可以让计算节点支持每台服务器对延迟敏感的虚拟机，从而显著的降低成本。总的来说，网络节点和存储节点对性能的要求最高，因此在云数据中心看到了这些节点最早开始100G的部署。对于需要高吞吐量的节点，原生SR-IOV驱动程序是最佳选择。

计算节点的VM虚拟化已成为云数据中心的普遍场景。不幸的是，基于内核的虚拟交换机（例如：Open vSwitch或OVS）只能提供200Kpps的吞吐量。带有VirtIO接口的基于用户空间DPDK轮询的vSwitch可以提供更好的性能，OVS-DPDK性能高达7.5Mpps，但这是以完全占用2个物理CPU核为代价的。这提供了25倍的性能改进，足以满足许多客户对计算VM的吞吐量要求。然而，OVS-DPDK以牺牲效率和增加资本支出为代价的方式提高了性能。DPDK应用程序性能的扩展与专用CPU Core的数量成正比。

云提供商通常更关心数据中心的高效率，因此这样可以向客户售卖更多的虚拟机以赚取收入。因此，与CPU内核相关的软件驱动加速会降低云数据中心的总体基础设施效率。

3 以太网网络适配器技术趋势

以太网速度的发展速度超出了CPU处理能力。现有的软件和硬件接口并不足以随着CPU的改进而扩展。在过去几年中，硬件供应商在其驱动程序中引入了许多创新，以解决数据包速率、带宽、延迟和CPU利用率的优化问题。随着时间的推移，驱动程序不断被重写和优化，硬件也随着功能的增加而变化。网卡的软硬件接口也代代不断更新。鉴于这一现实，我们知道要充分满足更加苛刻的应用程序性能，硬件接口锁定是个错误的做法。以太网NIC接口应该使硬件供应商能够持续创新以提供最佳的性能。正确的方法是抽象硬件处于操作系统驱动程序级别。锁定映射到VirtIO等软件接口“行业标准”的硬件API意味着对性能、可扩展性和灵活性的巨大妥协。

对性能的需求是巨大的。以太网驱动程序期望性能达到每秒上亿个数据包。锁定存储接口 NVMe是正确的，尽管它会使性能下降一个数量级，导致I/O速率低得多。硬件/软件接口可以标准化较低的速率，但是当您需要处理更高的速度时，标准化将无法跟上快速增长的需求。现在，原生的或SR-IOV驱动程序，是节省CPU内核的同时获得最佳性能的唯一方法。

4 什么是 VirtIO 加速？

图1 VirtIO 加速架构

VirtIO是标准软件接口，可将单个物理设备虚拟地暴露给多个VM。当前的VirtIO实现需要一个Hypervisor（又名 VirtIO 后端虚拟主机）来处理VM（又名VirtIO前端）发送的VirtIO请求，以与物理NIC驱动程序进行通信，这会消耗CPU资源。硬件加速的VirtIO架构意味着后端（至少是数据路径）在硬件中实现，从而释放Hypervisor资源以实现更高的数据包速率。

5 VirtIO的优势

以下是VirtIO API的优势：

• VM中的通用VirtIO驱动程序

• 硬件供应商不可知，因为它是一个软件API

• 性能足够好

1. 高于非加速VirtIO
2. 低于基于SR-IOV的IHV（独立硬件供应商） VF的速率

• 降低了NIC仿真的CPU使用率

• 实时迁移支持

VirtIO接口是在软件中设计和实现的，但是可以在硬件中实现此API的一些加速。但是，由于VirtIO的低级软件性质，它无法实现与SR-IOV等原生硬件虚拟化接口相同的性能和效率。这并不是说它不能进化以实现更高的性能和更高级别的功能，但是这种进化必然需要遵循与现有SR-IOV相同的路径，并且需要开发API以支持更高级别功能的加速。VirtIO要实现这些目标，需要克服许多挑战，如下所述。

6 VirtIO加速面临的挑战

原生驱动程序存在于上游内核和许多Linux发行版中，包括RHEL、CentOS、Canonical、Ubuntu、SUSE等。对服务器的部署来说，NVIDIA Mellanox驱动程序架构支持标准OS的驱动程序，并且向后和向前兼容。该驱动程序开箱即用，具有业界最佳的SR-IOV性能。SR-IOV设备驱动程序必须安装在操作系统映像中是一种误解。相反，它作为原生驱动程序的一部分已经包含在内。NVIDIA将所有驱动程序上传到上游，因此它们默认包含在大多数Linux操作系统中。对于任何在上游不可用的功能，NVIDIA支持OFED作为处理此类异常的机制。

而SR-IOV则不同，并非所有操作系统都支持VirtIO加速。据说，标准VirtIO驱动程序需要更改才能在硬件中实现。因此，要部署VirtIO解决方案，您必须修改操作系统并安装此类驱动程序。

使用原生驱动程序时，处理硬件问题很常见。原生驱动程序不仅能够适应性能优化，而且能够处理硬件和固件问题，并解决硬件设备可能存在的一些问题。将VirtIO软件接口锁定到硬件中还会给硬件供应商带来风险，如修复软件问题的能力，使现场的某些设备失效，以及损害正确性、性能和安全性等等。

7 硬件vDPA

最终在硬件中加速VirtIO，必然会遵循已有硬件加速接口所走过的相同路径。这就是硬件 vDPA发挥作用的地方。硬件vDPA在NIC端实现VirtIO标准。这允许主机上的VirtIO接口被NIC映射和处理。硬件vDPA将虚拟队列映射到硬件队列。这种方法允许使用相同的软件接口，同时享受virtio-net到vhost到NIC的更高性能。在硬件中运行VirtIO提供了足够好的性能，比软件VirtIO更好，尽管它不如SR-IOV快。此外，硬件vDPA的批准有助于克服基于软件的DPU的一些其他挑战，包括降低CPU利用率和支持实时迁移。

8 SR-IOV加速

网络功能虚拟化(NFV)和其他性能敏感的云用例等新兴技术要求网络基础设施内的数据平面设备具有高性能（在带宽、数据包处理、低并且确定的延迟方面）。由于几乎所有VM流量首先由主机交换实体处理，这意味着实现软件虚拟交换机的本地主机CPU上的负载非常高。

因此，提供对VM的网络访问的传统方式无法满足这些性能要求。

SR-IOV是PCI-SIG的规范，它允许单个物理设备将多个虚拟设备暴露给更高级别的软件。这些虚拟设备可以安全地分配给Guest虚拟机，让他们可以直接访问硬件。使用虚拟化功能的硬件加速可以直接降低虚拟机Hypervisor上的CPU负载，从而获得更好的性能和更低的延迟。

SR-IOV加速的好处是可以释放Hypervisor资源，但是，在基于SR-IOV的实现中，VM使用特定于供应商的本机物理设备接口直接与物理设备通信。SR-IOV是加速存储解决方案（包括 RDMA、NVMeoF）和网络解决方案（包括DPDK和ASAP2 OVS卸载）的行业标准。

NVIDIA Mellanox加速交换和数据包处理(ASAP2)技术利用SR-IOV显著加速虚拟交换机数据路径，同时释放CPU内核以运行应用程序和其他工作负载。控制路径API保持不变，从而允许对现有软件定义网络 (SDN) 控制器的透明支持。

图2 使用ASAP2 SR-IOV模式的OVS卸载架构

如图2所示，VM通过单根IO虚拟化(SR-IOV)虚拟功能(VF)建立对NVIDIA Mellanox ConnectX-5智能网卡硬件的直接访问，以在虚拟化环境中实现最高的网络I/O性能。与传统SR-IOV实现相关的问题之一是它完全绕过了Hypervisor和虚拟交换机，并且虚拟交换机不知道SR-IOV模式下VM的存在。因此，SDN控制平面无法影响这些VM的转发决策。

基于标准的OVS卸载技术（例如ASAP2）通过将数据包处理操作从虚拟交换机和慢速VirtIO 数据路径卸载到ConnectX eSwitch和更快的SR-IOV转发平面来克服这个问题。在将数据路径从VirtIO移动到SR-IOV时，ASAP2使OVS仍然能够通过用于SDN控制的标准开放流对eSwitch数据平面流水线进行编程。由于ASAP2利用了在所有主要Linux发行版中随时可用的SR-IOV驱动程序，客户可以简单地利用更快的数据包处理，同时释放CPU资源并实现最高的数据中心效率。

9 SR-IOV的实时迁移支持

正在为SR-IOV实施实时迁移。实时迁移并不是VirtIO独有的，它也可以支持SR-IOV设备。事实上，在Windows操作系统中，它已经支持多年，并且已经被大型云服务提供商部署。迁移过程包括在非常有限的时间内从原生驱动程序进入设备仿真并切换回原生驱动程序。这就是使用SR-IOV驱动程序进行迁移并能够获得最佳性能所需的全部内容。

10 SR-IOV加速的优势

以下是 SR-IOV 加速的主要优势：

• l裸机性能（BW、PPS、延迟）

1. 独特的IHV创新功能

• VM中的原生IHV驱动程序

1. 从ConnectX-4开始，硬件I/F完全向后和向前兼容

• NIC仿真的CPU使用率为零

1. 原生NIC暴露给VM

• 实时迁移支持

11 Benchmark比较

11.1 VirtIO加速

图3 打包速率

图4 吞吐量

备注：图3和图4为Intel公布的性能结果。

• 这些是基于VirtIO1.0（split Q）与VirtIO1.1（packed Q）规范的PCI开销之间差异的理论最大值（建模或模拟）结果。

• 实际性能数字将是这些理论最大数字的50-60%。

11.2 SR-IOV加速性能

图5 64B数据包的包速率

图6 1500B数据包大小时的吞吐量线速

请注意，图6中由于VirtIO软件接口的限制，OVS VirtIO吞吐量不会超过30Gbps。

使用SR-IOV数据路径加速的ASAP2 OVS卸载几乎可以扩展到线速（100Gbps ConnectX-5网络适配器上的91Gbps）。对于64字节的数据包，数据包速率达到6600万PPS，无需任何CPU消耗进行数据包处理。这些是客户验证的性能数字，而不是模型数字。

12 SR-IOV与VirtIO加速对比

	SR-IOV加速	VirtIO加速
硬件接口-标准化	SR-IOV PCIe标准	由vDPA行业标准驱动
硬件接口兼容性	向后和向前兼容PF和VF，从ConnectX-4开始	ConnectX-6 Dx和BlueField-2
Distribution支持	Inbox + upstream（ConnectX-5 及以上）	Upstream并集成到RHEL中
网络性能	最好， 10倍于基于软件的解决方案	有限的， 5倍于基于软件的解决方案
CPU 使用率降低为零	零	部分减少
实时迁移	支持的	支持的
特征	支持来自Guest的RDMA，来自Guest的IPsec、VNF加速	不适用
兼容性	Guest需要驱动	无缝整合

表1 加速SR-IOV与VirtIO的特性比较

• 数据包速率性能：SR-IOV 66 Mpps vs. VirtIO 10-15 Mpps。NVIDIA接口针对最高性能进行了调整——VirtIO主要针对软件性能进行了调整（即使如此，VirtIO1.1中的改进也在进行中）。

• 吞吐量：SR-IOV的线速 (100Gbps) vs. VirtIO的最大30Gbps

• 延迟：SR-IOV为0.6微秒

• 减少服务器资源占用率：SR-IOV的 CPU使用率为零，VirtIO降低CPU使用率，但不是零CPU使用率。

• 没有特殊硬件：今天的竞争对手在昂贵且难以编程的FPGA NIC或基于SoC的NIC上支持VirtIO。SR-IOV加速适用于所有NVIDIA适配器系列，包括经济型ConnectX (ASIC NIC)或高度可编程的BlueField DPU (SoC NIC)。

• 驱动程序支持：SR-IOV和VirtIO驱动程序在所有主要的Linux发行版中都可用。从VirtIO 更改为SR-IOV数据路径，反之亦然，这是一个配置旋钮设置，不需要专门的VNF开发工作。

• 硬件加速：NVIDIA SR-IOV接口提供了许多卸载，例如OVS、RDMA、NVMeoF，这些在VirtIO接口中根本不可用。SR-IOV允许VM直接利用这些卸载。

13 结论

使用SR-IOV和VirtIO进行硬件加速各有利弊。VirtIO是一个完善的I/O虚拟化接口，它是在纯软件框架内开发的。SR-IOV技术的开发正是为了支持网络功能的高性能和高效加速。不断发展的前进方向是通过硬件vDPA，它将VirtIO驱动程序的开箱即用可用性与硬件加速的性能提升相结合。

这里真正的解决方案不是选择其中一个，而是提供灵活的硬件加速和开放的软件API，以支持尽可能广泛的应用程序。最终，混合方法将在同一硬件中提供VirtIO和SR-IOV硬件加速选项。因此，无论采用哪种虚拟化方法，拥有能够同时支持两者的灵活硬件对于所有应用程序实现最高性能和可扩展性至关重要。

---

关注“软硬件融合”公众号，回复“介绍PPT” 下载软硬件融合技术介绍PPT。

《软硬件融合》最新直播回放：https://aijishu.com/l/1110000000215003。

---

长按扫描二维码或公众号回复“加群”，加入“软硬件融合”技术讨论群：