1 介绍
Apsara vSwitch (AVS) 是云中关键的单主机转发组件，为虚拟机、容器、裸机等计算实例提供连接和管理，类似于开源和其他行业 vSwitch [1, 36, 46 , 47,53]。除了基本功能外，AVS还支持租户的高级功能，例如流量镜像[11, 19]和Flowlog[8, 16]。为了实现这一目标，大量预定义的策略表促进了基本和高级功能，因此需要有效的数据包匹配来确定操作。因此，加速“匹配动作”、提升AVS转发性能仍然是我们不变的追求。
在过去的十年中，我们将各种优化方法，包括用户空间和轮询模式驱动程[13,29,35,42,52,54,61]集成到软件AVS中，并实现了10 Gbps/1.5的性能每个 CPU 核心的 Mpps。尽管有这些改进，软件AVS 仍然达不到现代网络接口控制器 (NIC) 的线路速率和 ~100 Gbps 带宽，这一点已在 [57] 中警告过。这一不足促使我们将智能网卡与硬件加速器结合使用，例如现场可编程门阵列 (FPGA) 和专用集成电路 (ASIC)，以有效卸载“匹配操作”任务 [30, 50]。
为了解决云数据中心中网络流量分布不均的问题并加速大多数流行流量[27, 55]，我们研究了现有的工作，发现一些主流解决方案将数据包转发分为两个独立的数据路径：运行整个 vSwitch 的软件数据路径，以及充当转发缓存的硬件加速路径[5,6,12,37]。在本文中，我们将这种设计称为“Sep-path”。由于其侵入性最小且集成简单，我们选择“Sep-path”来加速 AVS，而无需对现有软件框架进行重大更改。
然而，“Sep-path”架构在aliyun的部署，除了在处理热门流量方面的优势之外，也给AVS带来了一些挑战。大规模部署带来的问题可以分为三类：
- 首先，租户流量数据路径选择的不确定性导致性能不可预测。由于硬件限制，AVS 中的“matchaction”任务并不总是在硬件数据路径中实现。在至少 10% 的情况下，“匹配操作”任务不适合在硬件加速器中实施，性能会受到影响，并且服务级别协议 (SLA) 可能无法得到保证。
- 其次，硬件加速器较长的开发生命周期阻碍了AVS的演进。“Sep-path”架构需要在软件和硬件加速器中并行设计和实现“匹配动作”任务，以适应新兴的云网络服务，从而降低 AVS 的迭代速度[39,44,64]。
- 最后，“Sep-path”架构由于引入了硬件加速数据路径而增加了维护成本。aliyun统计分析表明，65%的AVS部署问题源于硬件和软硬件交互，进一步加剧了开发周期过长的问题。
在本文中，我们介绍了 Triton，这是一种灵活的 AVS 硬件卸载架构，旨在解决这些限制。与“Sep-path”架构相比，Triton 在单个管道中执行所有数据包处理，分为三个阶段：硬件预处理器、软件处理和硬件后处理器。为了得出合理的功能划分，我们测量了 AVS 在典型工作负载下的 CPU 使用率（第 4.1 节），并选择了以下分布：预处理器和后处理器阶段利用硬件来实现通用但耗时的任务（例如，解析、碎片和加密），用于加速软件处理阶段，该阶段运行高度灵活的“匹配操作”任务（§4.2）。
为了最大限度地发挥硬件加速的潜力并缓解 Triton 的瓶颈，我们采用了一系列硬件-软件协同设计（第 4.3 节）。这些技术包括硬件中基于流的数据包聚合机制和软件中的矢量数据包处理，以提高数据包速率（第 5.1 节），以及对巨型帧的支持和用于增强带宽的新型标头有效负载切片方案（第 5.2 节）。我们的评估表明，这些协同设计使 Triton 能够实现与“Sep-path”中的硬件数据路径相当的数据包速率和带宽，同时保留软件灵活性（§7）。在云中部署 Triton 的见解和经验教训可以为学术界和其他云供应商提供宝贵的指导（§8）。
具体贡献可概括如下：
- 首先介绍aliyun加速AVS的经验，并介绍灵活的硬件卸载架构Triton。与我们之前基于“Sep-path”架构的解决方案不同，Triton 旨在通过统一数据路径和建模以选择性地将通用网络任务卸载到硬件加速器来平衡性能和灵活性。
- 其次，我们充分探索硬件和软件协同设计，以解决 Triton 软件部分的潜在性能问题，包括矢量数据包处理和标头有效负载切片，以提高数据包速率和带宽。
- 第三，我们在云中部署Triton来加速AVS并进行实际评估。结果表明，除了可预测性能和迭代速度方面的优势外，Triton 还实现了与我们之前基于“Sep-path”架构的解决方案相当的性能加速。通过软硬件协同设计，Triton 将 AVS 连接建立率提高了72%，仅比“Sep-path”中的硬件数据路径增加了2μs的延迟。
2 背景和动机
在本节中，我们首先介绍AVS及其软件框架从内核空间（版本1.0和2.0）到用户空间（版本3.0）的演变。基于AVS 3.0，我们在广泛使用的“Sep-path”架构下开发了硬件卸载解决方案。不幸的是，我们发现它带来了包括大规模运营下性能不可预测和灵活性有限等问题。
2.1 Apsara vSwitch (AVS)
AVS 是 Achelous 网络虚拟化平台 [63] 的组成部分，其任务是为虚拟机、裸机和容器等实例提供网络连接和管理。 AVS 的核心功能是有效地将传入数据包与一系列预定义的策略表进行匹配，并执行相应的操作，这对于转发性能至关重要。
与主要关注无状态转发和可移植性的开源vSwitch不同，AVS是为有状态云服务量身定制的。首先，无需跨平台部署的需求，AVS可以在硬件和软件方面进行定制以实现高性能。例如，AVS中的流表是为许多有状态服务定制的，我们提出了诸如“会话”结构的优化（参见第2.2节）。其次，在云网络中管理大规模表条目的压力下，我们在AVS中对数据平面和控制平面进行了更灵活的解耦，以实现网络的快速收敛[63]。第三，AVS依赖于更强的运维能力，包括统计、诊断、可视化等。其中，可视化还要求我们为租户提供流量镜像[11, 19]、Flowlog[8, 16]等多种工具。最后但并非最不重要的一点是，AVS 需要具备编程灵活性和热升级功能，以支持快速发展的云基础设施中不断出现的新服务[1, 39, 44, 46, 47, 53, 64]。
2.2 AVS 加速的演变
内核模块。 AVS的发展始于十几年前云刚成立的时候。 AVS 1.0最早的版本并不是一个独立的进程，而是一个系统服务的集合。在AVS 1.0中，我们充分利用Linux内核中现有的Netfilter模块[24]来实现各种网络功能。例如，我们使用流量控制[23]来实现服务质量（QoS）功能，并使用iptables[22]来实现网络安全组。为了解决这些分布式模块的性能和管理问题，并减少对Linux内核的依赖，我们开发了类似于当前vSwitch的AVS 2.0。它包含两个进程：内核空间的数据包转发进程和用户空间的管理守护进程。在报文转发过程中，AVS 2.0对业务层和公共层进行了抽象，可以灵活迭代，同时提高转发性能。
图1.AVS 的架构。在slow path上灵活扩展匹配表，在fast path上通过“会话”加速有状态处理
用户空间加速。\为了最大限度地减少内核空间数据包处理的开销并消除对 Linux 内核版本的依赖，AVS 3.0 采用数据平面开发套件（DPDK）[13] 作为用户空间加速解决方案。图1说明了AVS 3.0中快速路径和慢速路径设计的实现，旨在提高数据包转发率。快速路径设计的核心是“会话”结构，它包含一对双向流表条目及其关联状态。因此，当通过快速路径处理数据包时，它们的流条目会被有效地索引到“会话”中以进行状态处理，从而消除了用于连接跟踪的单独模块。这种基于会话的架构显着提高了网络性能，特别是对于NAT)和负载平衡 (LB) 等有状态服务。然而，AVS 3.0 每个 CPU 核心 10 Gbps/1.5 Mpps 的性能仍然无法与现代网卡的线速相匹配。更糟糕的是，我们发现在主机上部署 AVS 还会导致与租户虚拟机的资源争用，特别是总线和缓存资源。这些因素促使我们引入主机外部的硬件来卸载 AVS。
基于智能网卡的系统芯片 (SoC) 上的软件卸载。通常，智能网卡中加速vSwitch有两个极端方向：硬件全卸载和SoC CPU内核上的软件实现。硬件全卸载方法利用ASIC/FPGA将数据包处理管道完全嵌入到硬件中，以牺牲灵活性为代价实现高性能。相比之下，基于软件的方法完全在智能网卡的 CPU 内核上运行 vSwitch，将灵活性置于原始性能之上。但是我们在 AVS 上采用这种方法的实验部署表明，虽然它成功地消除了主机和 VM 内存之间（即 virtio [56] 设备的前端和后端之间）的数据包复制，但它并没有提高整体性能表现。该限制主要源于智能网卡的 CPU 内核与主机 CPU 内核相比性能较差，这是功率限制的结果。
Sep-path”硬件卸载架构。为了在加速 AVS 的两个极端方向之间进行折衷，我们选择实现类似于 VFP 加速解决方案 [37] 和 Mellanox OVS 卸载方法 [6] 的卸载架构。我们将其命名为“Sep-path”，因为它管理两个独立的数据路径：硬件数据路径充当加速的流缓存；软件数据路径在 SoC 上运行整个 vSwitch。基于“Sep-path”的AVS加速方案如图2所示，该方案是在我们内部开发的SmartNIC上实现的。 智能网卡分为软件 (SoC) 和硬件 (FPGA) 组件，通过 2 × 8 PCIe 4.0 通道连接，并在两者之间执行数据包转发逻辑。硬件路径的特点是卸载流行的流表条目，加速缓存的流，而未缓存的流则由软件处理。 “Sep-path”架构引入了额外的硬件转发路径，并且需要对现有的AVS软件框架进行最少的修改，这使得我们能够在短时间内部署它。但也正是这两条转发路径割裂了AVS中原本统一的性能指标和可编程性，给大规模云部署带来了挑战。
图2.AVS 的“Sep-path”硬件卸载架构。我们已经将其部署在我们自主开发的SmartNIC上并运行了多年。
2.3 部署问题
经过几年的部署，我们发现“Sep-path”架构存在以下问题：
性能不可预测。我们的部署经验和分析挑战了平均数据准确反映“Sep-path”架构效率的观念。如表1所示，我们对云4个典型区域的流量分流率（TOR，按分流流量字节/所有流量字节计算）进行了评估，发现存在不一致之处。例如，即使在平均 TOR 最高的区域 C 中，只有 1.9% 的主机的 TOR 低于 50%，但仍有 25.5% 的租户虚拟机未能从硬件卸载中显着受益，因为其一半流量仍通过软件数据处理小路。在区域 D 中，近一半虚拟机的 TOR 低于 50%，而该区域的平均 TOR 为 81%。这表明只有一小部分长连接和大流量的租户贡献了云数据中心的主要TOR，而大多数租户的流量由于短连接和硬件资源的限制而仍然无法分流。硬件资源限制的一个典型例子是，对于Flowlog产品来说，硬件数据路径只能存储数万个流的RTT，多余的流必须经过软件数据路径。因此，这些场景下的虚拟机网络性能受到软件转发能力的限制，影响了SLA的保证能力。此外，单个主机上过多的未卸载流量可能会导致 CPU 资源争用，从而对租户体验产生不利影响。
表1.典型区域主机和虚拟机级别的流量卸载率 (TOR) 分布。
迭代速度降低。
在云平台上，迭代对于支持新服务和解决错误至关重要[39,44,64]。然而，未来服务、协议和操作的不可预测性使 AVS 的适应性变得复杂，需要直接修改源代码，而不是更简单的 SDN 式编排。在过去的三年里，我们已经将 20 多项新功能集成到 AVS 中，其中一项需要修改解析器，三项需要调整匹配字段（例如添加实例 ID 或新协议头），还有七项需要新的“操作”。 “Sep-path”架构加大了设计和开发的工作量，要求软件和硬件数据路径并行工作。这导致迭代速度降低，从每年 4-5 个版本下降到每年约 2-3 个版本。
维护成本高。
部署AVS加速的“Sep-path”架构显着降低了维护效率，特别是增加了错误识别所需的时间。例如，出现丢包的情况，首先需要确定丢包的数据路径（硬件或软件），然后进行详细分析。硬件路径故障排除特别耗时，因为它很大程度上依赖于读取寄存器中的值，而没有任何有用的运行时调试工具。在某些情况下，这通常会导致花费较长时间来分析硬件和软件之间的流缓存条目和会话的差异。近两年的部署运营统计表明，在所有的功能bug、设计缺陷和产品限制中，25%是由硬件引起的，40%是由软硬件交互引起的（由于两条数据路径之间复杂的同步），只有 35% 是仅由 AVS 本身引起的。此外，涉及硬件的问题通常需要更多时间才能解决。
需要澄清的是，“Sep-path”架构遇到的部署挑战并非本质上是由于其设计造成的，它涉及两个独立的转发路径。从我们的角度来看，“Sep-path”代表了一种常见的优化策略，以最小的修改促进热门流量的加速。然而，异构硬件平台（即CPU和FPGA）之间的性能和可编程性差异呈现出巨大的差距。这一差距使得“Sep-path”架构不太适合快速迭代的云虚拟交换机。
3 Triton设计概述
为了协调两个独立数据路径不一致的性能和编程能力，我们正在努力统一它们并开发Triton，这是 AVS 的新一代硬件卸载架构。 Triton最大的改进在于，数据包在硬件和软件上都是串行处理的，并且工作负载在它们之间合理分配。这允许可预测的性能和编程灵活性来支持新兴服务。
3.1 设计概述
如图 3 所示，Triton 架构通过硬件模块和软件组件串行处理所有数据包。 Triton 与之前的“Sep-path”解决方案的主要区别在于其统一的数据路径。这种架构转变有几个好处。首先，它促进了可预测的性能，这对于保证租户的 SLA 至关重要。其次，它显着降低了开发和运营成本。
图3.Triton 架构概述。通用数据包处理工作负载被卸载到硬件以进行加速，而灵活的逻辑则留给软件。
随着 Triton 架构中软件和硬件的数据包处理从并行处理过渡到串行处理，工作负载分配也随之发生变化。与“Sep-path”不同，“Sep-path”的工作负载分配取决于“match-action”是否可以卸载，而 Triton 允许在数据包处理的不同阶段进行更细粒度的分配。这使得数据包转发能够进行精确的工作负载建模，从而为软件分配灵活的操作，为硬件分配固定但耗时的任务。Triton将能够在性能和灵活性之间取得平衡，有效地解决第2.3节概述的限制。
为了在 Triton 中实现平衡，我们将数据路径抽象为三个部分：硬件预处理器、软件处理和硬件后处理器（见图 3）。 Triton中的数据包处理顺序如下。最初，在预处理器阶段，硬件有效地处理 I/O 卸载任务，例如 TCP 段卸载 (TSO)、UDP 片段卸载 (UFO) 和数据包标头解析。随后，硬件上的匹配加速器对数据包进行匹配，其目的是加速软件端的匹配阶段。当数据包通过预处理器时，它们与包含中间处理结果的元数据一起被软件调用，这使得 AVS 能够加速软件“匹配操作”。软件处理后，数据包通过直接内存访问 (DMA) 重定向到硬件后处理器，以进行最终的 I/O 操作，包括加密和传出。 Triton中的详细工作负载分布将在第4节中描述。
3.2 Triton 的优势
可预测的性能。
Triton 中的统一数据路径提供可预测的网络性能以及精确的性能上限和下限，从而确保符合性能 SLA。与之前的“Sep-path”架构中软件路径和硬件路径之间的显着性能差距不同，软件 AVS 内的快速路径和慢速路径之间的差距不太重要。差异源于后者的路径选择受到租户行为的影响，而不是工作负载是否可以卸载。例如，建立新连接的数据包在慢速路径上消耗更多的 CPU 周期，而已建立连接的数据包在快速路径上传递得更快。这一事实与guest OS内的协议堆栈处理类似，这比AVS更有可能成为瓶颈。因此，Triton 下软件和硬件路径的统一使虚拟机网络性能指标更符合租户的期望。
灵活性和迭代效率。
在Triton中，软件和硬件之间的工作负载分配经过精心设计，以实现性能和灵活性之间的平衡。在第4节中，我们将说明如何建模并有效地将通用逻辑卸载到硬件，同时保持软件的编程灵活性。这种方法加速了迭代，因为可以将附加功能无缝添加到软件中，而无需更改静态硬件模块。
可维护性，降低运营成本。
，Triton 最大限度地减少了冗余资源利用率，从而节省了 SmartNIC 上的资源。这些节省的资源可以分配给其他管理程序服务，例如存储。此外，Triton 为软件分配灵活、动态的工作负载，增强了调试和故障排除能力。因此，可以通过全链路抓包、动态代码替换等方法来提高运行效率。 在第7节中可以看到Triton和“Sep-path”之间的操作工具的综合比较。
**硬件加速而不牺牲灵活性。**在基于软件的卸载架构中，硬件主要提供 Rx 和 Tx 功能，数据包处理完全在 SoC 内核上处理。虽然这种方法减少了 I/O 开销，但它经常面临性能问题。相比之下，Triton 引入了硬件模块，有助于集成特定数据包处理阶段，从而增强加速。这种集成允许 Triton 将尽可能多的耗时任务（例如解析）卸载给硬件，以在不牺牲灵活性的情况下加速。
**实施成本低。**从“Sep-path”迁移到 Triton 的相关成本是合理的。正如第6节所讨论的，我们的实现表明，迁移可以通过消除硬件(FPGA单元)中的冗余逻辑并向AVS引入少于2000行代码来完成。
4 Triton 数据包管道
在本节中，我们重点关注通过有效建模 AVS 数据包处理任务以及在软件和硬件之间分配工作负载来优化 Triton。我们首先介绍 AVS 工作负载模型，然后描述 Triton 的数据包管道设计，最后讨论相关的性能问题。
4.1 AVS 工作负载模型
我们对 AVS 数据包处理管道进行建模，并将其分为三个阶段：解析、匹配和操作执行。
**解析阶段。**收到数据包后，AVS 会执行各种操作，例如验证、标头解析和匹配字段提取。在此阶段，由于CPU等待多个内存访问以从多个报头层检索字段，因此引入了延迟。如表 2 中的性能结果所示，这些操作占转发专用 CPU 使用率的 27.36%。
表2.软件AVS中数据包处理过程中各阶段的CPU使用率，以及Triton中理想的工作负载分配。
**匹配阶段。**初始解析后，AVS匹配相关字段以识别相应的流表项。该管道包含通常用于第一个数据包的Slow Path和旨在加速后续数据包的Fast Path。重要的是要认识到，仅静态规则查找可能不足以进行状态数据包处理。例如，状态ACL要求一旦发出请求数据包就接受所有回复数据包；在某些场景下，需要记录物理主机的IP/MAC作为回复报文的下一跳。可见，匹配是一项相当耗时且灵活的工作。我们的研究结果表明，即使对于主要在Fast Path上处理的长期连接，哈希查找也约占 CPU 消耗的 11.2%。
操作执行阶段。 AVS中的动作执行阶段具有灵活性的特点，执行从匹配阶段获得的所有动作，包括VXLAN封装、NAT和分片[43]。它通过扩展其操作集来适应新服务。性能测试（使用 perf ）表明基本的覆盖网络转发操作消耗了大约 24.32% 的 CPU 资源。
除了这三个阶段之外，两个额外的工作负载也会影响 AVS CPU 使用率。 NIC 驱动程序处理（以 virtio 驱动程序为例）占 CPU 使用率的 29.85%。这归因于它在数据包传输和接收中的作用，包括全面的校验和计算。值得注意的是，覆盖和底层协议报头都需要校验和（例如，在 L3 和 L4 报头中）。此外，操作代码执行占 CPU 总消耗的 7 .17%。
4.2 Triton 中的数据包管道
基于上述模型，我们精心分配工作负载并设计了Triton中的数据包处理管道。
**解析（在硬件上）。**如图 3 所示，我们的设计在硬件中加入了专用的预处理器模块，以减轻整个解析阶段的负担。为了确保解析结果有效传输到软件，我们设计了一种存储中间结果的元数据结构。当接收到数据包时，预处理器模块对其进行验证并提取各个标头层中的五元组以方便数据包匹配。然后，提取的中间体存储在元数据结构中。解析完成后，元数据结构将位于原始数据包之前，随后通过 PCIe 通道传递到软件。
**匹配（硬件和软件）。**在匹配阶段，我们的目标是利用硬件模块来减轻软件Fast Path上的哈希查找。
如图4所示，我们在预处理器模块中引入了“流索引表”来进行加速。该表不存储包含匹配字段和操作的整个流条目。相反，它充当由五元组哈希计算的密钥与相应的“flow id”之间的映射。 “flow id”充当软件AVS内“流缓存阵列”（如图4所示）内的索引。
图4.硬件辅助软件包匹配
一旦数据包通过查找“流索引表”获得了相应的“flow id”，该“flow id”将被存储在元数据中并传输给软件。此外，无论数据包是否在“流索引表”中匹配，预处理器都会将数据包与元数据一起写入HS环中。 HS 环代表位于 SoC DRAM 中的队列，有助于硬件和软件之间的交互，如图 3 所示。软件将执行必要的后续匹配操作。
当数据包到达软件 AVS 时，SoC 上的 CPU 内核将尝试通过快速路径处理数据包，如图 4 所示。CPU 从元数据字段中检索 flow id 并直接访问相应的流条目。但是，如果硬件匹配失败并且flow id为空，则需要进行哈希查找来定位相关的流表项。如果报文在Fast Path上找不到流表项，就会在Slow Path上通过一系列的匹配表进行处理，甚至进行状态处理。在Slow Path中成功匹配后，生成的操作将合并到一个列表中。为了加速同一流中后续数据包的处理，在Fast Path上生成流条目，包括哈希键、五元组和操作列表。
**操作执行（在软件上，I/O 留给硬件）。**匹配后，CPU遍历流表项内的操作列表，执行VXLAN封装、NAT、QoS等各种灵活动作。相反，硬件（后处理器）处理 I/O 密集型操作，例如碎片和校验和。此方法有效降低了与 NIC 驱动程序校验和相关的 CPU 开销（物理 NIC 为 8%，vNIC 为 4%）。通过主要依靠软件来执行操作，Triton 提供了增强的灵活性和可扩展性。例如，系统可以轻松地整合复杂的操作来支持巨型帧（参见第 5.2 节）。
Triton 的数据包处理管道还提供了简化更新和同步的额外优势。这是通过消除硬件中的流缓存来实现的，从而消除了软件与硬件同步流信息的要求。此外，由于每个数据包都经过硬件和软件组件的处理，因此可以通过嵌入元数据中的指令无缝执行“流索引表”的更新。因此，Triton 的数据包处理管道中的更新和同步过程变得更加简化。
4.3 潜在的性能问题
虽然 Triton 的统一数据路径设计在可预测的性能和灵活性之间提供了良好的平衡，但必须认识到，将软件合并到每个数据包的数据路径中可能会引起潜在的性能问题。这些问题包括以下几个方面： *
**数据包速率问题。**在Triton中，每个数据包的处理都涉及耗时的软件操作，包括数据包匹配和动作执行。每秒可以处理的数据包总数受到CPU处理能力的限制。因此，与“Sep-path”解决方案相比，Triton 可能会削弱硬件加速在数据包速率性能方面的优势（以 PPS（每秒数据包数的缩写）来衡量）。
**带宽问题。**由于每个数据包都需要在硬件和软件之间移动，因此可用的 PCIe 带宽可能会耗尽。在所示的 SmartNIC 中，硬件模块和 SoC 之间的数据包传输是通过 DMA 操作实现的（见图 2）。对于 Triton，每个数据包都从蓝色硬件模块 DMA 传输到橙色 SoC 进行处理，然后再通过 DMA 传输回硬件模块。这两个 DMA 操作发生在同一 PCIe 总线上，导致可用带宽减半。
值得注意的是，这些挑战对传统软件AVS架构(如基于SoC的软件卸载解决方案)构成了巨大障碍。然而，在Triton中，这些问题可以通过硬件加速模块的利用来有效地解决。通过第5节重点介绍的优化，我们证明了Triton可以实现与“Sep-path”中的硬件转发相媲美的高PPS和带宽性能。
5 性能优化
在本节中，我们将介绍 Triton 的技术创新，以有效解决潜在的性能问题，包括数据包速率性能和带宽限制。
5.1 数据包速率提高
通过对软件处理的观察和分析，我们发现广泛使用的批处理优化并不能让CPU高效地处理数据包。当处理一批数据包（例如32或64个数据包）时，CPU将按顺序对每个数据包执行“匹配动作”（见图5(a) ）。由此可见，批处理优化并不能降低整体的数据包匹配次数和指令缓存未命中率。为此，我们提出了一种基于流的数据包聚合机制，利用硬件将属于同一流的数据包聚合成一个向量，以便软件可以进行向量包处理（VPP，只需要对一个向量进行一次匹配）来保存CPU 周期。与其他现有的基于软件的矢量数据包处理解决方案[31, 42]相比，利用硬件聚合同一流的数据包可以最大限度地提高数据包速率。
图5.Triton 中批处理和矢量处理的比较。
**基于流的数据包聚合。**如图5(b) 所示，Triton中的预处理器模块采用基于流的数据包聚合机制将属于同一流的数据包分组为向量。聚合发生在数据包通过解析器和匹配加速器之后。当数据包与“流索引表”中的条目匹配时，将根据“流id”进行聚合。反之，如果数据包匹配失败，则会根据五元组进行聚合。随后，数据包向量将被传输到 HS 环，向量大小在第一个数据包的元数据中指示。为了最小化延迟，分组聚合模块遵循最佳努力原则，其有效实现将在第8节中讨论。
**矢量包处理(VPP)。**在 Triton 中，软件包处理也转变为基于矢量的粒度。如图 5(b) 所示，在从 HS 环接收到数据包后，CPU 从元数据中检索向量大小。随后，它向后遍历，直到获取向量内的所有数据包。对于每个向量，只需要一次匹配操作即可检索流条目和相应的动作列表。这种 VPP 方法显着减少了单个流内数据包匹配的次数。与传统的批处理优化（图5(a) ）相比，该技术极大地提高了数据包预取效率并提高了缓存命中率。这种方法的有效性将在第7.2节中展示。
5.2 带宽改进
Triton 通过两个基本原则实现带宽改进：增加数据包有效负载和最大限度地减少不必要的数据移动。在本小节中，我们介绍两种技术：云数据中心中的巨型帧支持和标头有效负载切片。
**巨型帧支持。**支持巨型帧对于提高带宽和传输效率至关重要。它增加了每个数据包的有效负载，减少了转发组件的性能压力。例如，使用 8500 字节巨型帧代替 1500 字节数据包可以将有效负载增加 14%，并将数据包速率需求降低多达 82%。
然而，在云规模数据中心中支持巨型帧比仅在特定集群中支持巨型帧带来了更多的兼容性挑战。有许多库存虚拟机和过时的硬件设备不支持如此大的最大传输单元 (MTU)，但需要与使用 8500 MTU 的虚拟机进行通信。更糟糕的是，大多数硬件交换机不支持片段和路径 MTU 发现 (PMTUD) 机制。这需要 AVS 协商 MTU 并确保虚拟机的网络连接。
为了解决这个问题，我们向 AVS 引入了路径 MTU 和新操作，以确保多 MTU 场景中的网络连接。控制器在向 AVS 发出路由条目时附加路径 MTU，从而了解目的地的最大可接受 MTU。然后，AVS 采用三个新操作（遵循 RFC [2,3,32] 标准）来处理超大数据包（见图 6）。对于小于路径MTU的数据包，AVS将照常转发该数据包。但当数据包大于路径MTU时，根据标准会有两种不同的处理。如果 IP 标头中的不分段 (DF) 字段设置为 1，则应丢弃数据包，并将包含路径 MTU 的 ICMP 消息发送到源 VM 以减少数据包长度。这种动作很复杂，并且在硬件中生成新数据包的成本太大，因此我们在软件AVS中实现它。但如果DF字段为0，则数据包应该被分片并发送出去。该动作是固定的并且与I/O相关，因此更适合在后处理器中实现以提高效率。
图6.Triton 确保多 MTU 场景下的连接。 VM2 充当仅支持 1500 MTU 的库存 VM
**标头有效负载切片 (HPS)。**为了减少软件和硬件之间不必要的数据移动导致的 PCIe 带宽占用，Triton 提出了一种称为标头有效负载切片 (HPS) 的技术。这种设计基于两个关键观察：AVS 中数据包处理的主要焦点主要在于数据包标头，有效负载通常占数据包中的大部分带宽。
HPS 的工作流程如图 7 所示。预处理器模块将数据包分为标头和有效负载部分。一旦预处理器完成匹配加速，只有数据包标头和相关元数据通过 HS 环传送到软件。当数据包标头通过软件管道进行处理时，有效负载将存储在 BRAM 中，直到标头完成软件中的操作执行并被发送回进行重组。这显著降低了软件和硬件之间 DMA 操作期间的 PCIe 带宽消耗。例如，转发8500字节数据包时，HPS可以节省大约97%的PCIe带宽。
图7.HPS 减少数据包移动期间的 PCIe 带宽占用
在完成软件处理并将数据包标头传输回硬件后，Triton 需要一种有效的机制来定位相应的有效负载并重建数据包。为了实现这一点，我们采用“有效负载索引表”来管理标头和有效负载之间的映射。在数据包划分期间，预处理器将有效负载索引附加到元数据。软件返回报头后，后处理器模块利用元数据中的索引在“有效负载索引表”中定位相应的有效负载，并将其重新组装成完整的数据包进行传输。
在实际部署中，我们发现HPS最大的问题是如果缓冲的payload不及时重新组装，BRAM可能会被耗尽。例如，当软件管道处理速度太慢或遇到异常时，头不会按时返回，并且没有足够的缓冲区来存储传入的数据包。为此，我们引入了超时和版本管理机制来解决这个问题。由于软件处理一批数据包只消耗几微秒，因此每个负载的超时值需要设置足够小，例如100us。然后，对于超时重用的有效负载缓冲区，我们可以通过在重组时比较版本来避免误用。
6 实施
在本文中，我们将 AVS 卸载架构的“Sep-path”版本与 Triton 版本进行了比较。两者都是基于我们内部开发的SmartNIC（也称为CIPU [10]）实现的，它在SoC上集成了FPGA硬件逻辑单元和Intel x86 CPU内核。从“Sep-path”到 Triton 的过渡涉及向 AVS 添加不到 2000 行代码，并减少硬件上冗余的 FPGA 代码。这一转变的人力投入很少，只需要几名工程师在不到一个月的时间内开发原型。 Triton 优化了资源使用，其预处理器和后处理器仅使用 57K 查找表 (LUT) 和 6.28 MB 缓冲区，与原始“Sep-path”架构相比，减少了 136K LUT。节省的资源可用于交换额外的 SoC CPU 内核以获得更高的网络性能，或用于服务其他虚拟机管理程序（例如存储和计算）。最后但并非最不重要的一点是，尽管我们当前的实现是基于 FPGA，但 Triton 的硬件模块有可能通过使用 eASIC [14] 等新技术来实现，以提高性能和成本效益。
7 评估
在本节中，我们初步评估了Triton相对于先前的“Sep-path”架构的增强，重点关注AVS的性能、灵活性和操作效率，在相同的硬件条件下。随后，我们评估了第5节中讨论的硬件加速技术的有效性。最后，我们在不同的流量设置下进行应用程序性能测试，包括长连接和短连接。
7.1 系统总体评估
首先，我们评估 Triton 和我们之前的“Sep-path”架构下的性能、灵活性和操作能力。两种架构下的硬件成本相当：“Sep-path”使用 6 个 CPU 核心和一个硬件数据路径，而 Triton 使用较少的硬件资源，SoC 上有 8 个 CPU 核心（多出的 2 个 CPU 核心是通过节省硬件资源获得的） 。
图 8.总体性能 图 9.延迟开销 图 10.可预测的性能
**Triton 系统性能。**图 8 对 Triton 和“Seppath”架构在带宽、PPS 和每秒连接数 (CPS) 性能方面进行了比较。我们使用 iperf [21]、sockperf [26] 和 netperf [25] 中的“CRR”模式分别测试带宽、PPS 和 CPS 性能。所有这些程序都运行在多个进程/线程上，以获得整个系统的最大转发性能。与“Seppath”中的软件路径相比，Triton将带宽和PPS分别提高了2倍和1.25倍。虽然与硬件路径的 24 Mpps 相比仍有不小的差距，但根据我们的运营统计，18 Mpps 足以加速大多数租户。 Triton 中的 PPS 性能未来还可以通过增加 CPU 核心数量来扩展。在 CPS 方面，Triton 与“Sep-path”相比表现出 72% 的改进。这是因为“Sep-path”中的硬件路径无法加速新连接的建立，而Triton的硬件辅助设计可以提升CPU效率。
关于延迟，Triton 由于 HS 环上的每个数据包交互而引入了大约 2.5μs 的延迟，如图 9 所示。但是，对云服务的影响可以忽略不计。这是因为 Redis [17] 和 Nginx [15] 等应用程序的延迟都是毫秒级的（参见第 7.3 节），而瓶颈在于 VM 内核处理。
**可预测的性能。**我们对路由刷新场景进行测试，以衡量可预测的性能。两种架构最初都支持 200 万个连接。我们在 17 秒开始刷新路由表，强制所有流量上调至慢速路径以更新流缓存。图 10 展示了 100 秒内不同架构中的 PPS。我们观察到“Sep-path”中的性能显着下降，比其初始性能（即软件/硬件差距）低约 75%，持续约 1 分钟。此时，CPU核心正忙于转发流量并向硬件下发流缓存条目，带来如此巨大的抖动。相比之下，Triton 的统一数据路径在几秒钟内仅经历了 25% 的性能下降（快/慢路径切换）。这表明Triton更有能力为租户提供可预测的网络性能。
**灵活性。**在灵活性方面，Triton可以轻松支持新功能并快速迭代新版本。与“Sep-path”相比，Triton只需要修改软件AVS，硬件模块不变即可演进。根据我们的发布记录，它显着缩短了50%以上的开发生命周期。
这个结果得益于细粒度的工作负载分布，它使Triton能够支持高度复杂的操作，如第5.2节中所示的PMTUD。
运营效率。 Triton 中的统一数据路径使故障排除变得更加容易。首先，通过减少同步，可以减少兼容性错误。其次，Triton的主要和灵活的工作负载都是通过软件实现的，这提供了更强大的操作工具。如表3所示，Triton支持每个关键点的数据包捕获，实现更详细的流量统计，并提供运行时调试功能。相比之下，在“Sep-path”的硬件路径上，我们缺乏这些重要的调试功能。我们需要注意的是，采用可靠的覆盖协议并支持多路径传输以避免云数据中心丢包已经成为一种趋势[51, 60]。在这种场景下，Triton提供了在逐包软件数据路径上实现覆盖协议栈的可行性，而这在“Sep-path”架构中很难实现。
表3.Triton 支持比 Seppath 架构更丰富的操作工具
7.2 加速技术评估
在本节中，我们将详细介绍第5节中的每项创新如何有助于带宽和PPS的改进。
图 11：HPS 改进带宽 图 12：VPP 改进 PPS 图 13：VPP 改进 CPS
**带宽改善。**图11证明了巨型帧和HPS在提高带宽方面的有效性。可以看出，每种技术在提高带宽方面都受到限制，因为 DMA 操作和每个数据包的数据包处理时间没有显着改善。但当巨型帧和HPS同时支持时，Triton可以实现与硬件转发相同的带宽。我们的实验证明Triton可以支持接近200 Gbps的带宽。如果物理服务器支持多个SmartNIC，则可以进一步提高带宽。
**PPS/CPS 改进。**我们通过测试来比较使用VPP前后的PPS和CPS性能。图 12 和图 13 表明，基于流的数据包聚合和矢量处理将 CPS 和 PPS 提高了 27.6-36.3%（6 核为 28%，8 核为 33%）。事实证明，硬件辅助加速方法可以显着降低软件转发时的CPU占用率，从而提高网络各维度的性能。
7.3应用程序性能
在本节中，我们部署实际应用程序来比较 Triton 和“Sep-path”架构的性能。我们选择Nginx作为代表应用，因为它广泛部署在云端，可以用来模拟各种流量特征。为了验证不同工作负载下的效果，我们选择长寿命连接和短寿命连接来代表生产场景中两种常见的工作负载类型。
图 14：Nginx RPS 性能 图 15：Nginx RCT（长 conn） 图 16：Nginx RCT（短 conn）
**Nginx RPS 性能。**图 14 说明了在 Triton 和“Sep-path”架构下具有长连接和短连接的 Nginx 的每秒请求量 (RPS)。在长连接测试中，Triton实现了278万的RPS，是“Sep-path”中硬件路径性能的81.1%，对于大多数租户来说已经足够了。在短连接测试中，Triton 比“Sep-path”高出 66.7%，达到 578.6K RPS，表明建立新连接的能力得到增强，并发性能更高。
**Nginx RCT 分发。**图 15 和 16 显示了请求完成时间 (RCT) 结果。在长连接的情况下，Triton 的延迟与“Sep-path”中的硬件路径的延迟相当（其中瓶颈在于 VM 内核）。在短连接的情况下，Triton 显着改善了长尾延迟。 p90时延降低25.8%至143.11ms，p99时延降低32.1%至590.08ms。
8 经验
我们在云上部署 Triton 已有多年，积累了丰富的运营经验。在本节中，我们将首先介绍我们在部署 Triton 时探索的一些有用实践，然后讨论 Triton 如何支持可靠传输和大规模机器学习网络。在8.2节中，我们将展示我们在AVS的开发和运行中探索的原理。
8.1部署经验
**在 Triton 中高效实现基于流的数据包聚合。**如5.1节所示，基于流的分组聚合策略需要基于向量的调度。在传统设计中，对不确定数量的数据包进行重新排序和调度会消耗过多的硬件资源并增加系统的复杂性。因此，我们尝试通过在实现中向预处理器添加足够的硬件队列来解决这个问题。在将数据包调度到 HS 环之前，我们使用 1K 硬件队列来存储基于五元组计算的哈希值的数据包。理想情况下，存储在每个硬件队列中的数据包应该属于同一流（或属于哈希冲突的多个流），从而消除了数据包重新排序的需求。然后，调度程序每次从每个队列中选择最多 16 个数据包，并将它们 DMA 到 HSring，然后软件驱动程序将计算向量中的数据包数量。每个数据包的 DMA 操作大约需要 16 ns 才能完成，因此调度另外 15 个数据包所造成的延迟可以忽略不计。
**Triton 中有限的 BRAM 避免了不必要的数据包丢失。**尽管我们采用了Triton与第5节中描述的技术，但仍然存在SoC CPU内核成为瓶颈并由于缓冲区耗尽而导致数据包丢失的风险。坏消息是，随着虚拟机可以使用更高端的 CPU 型号，这种情况会变得更加严重。在这种趋势下，增加硬件缓冲区大小和使用更强大的 SoC CPU 并不能消除风险。我们认为应该通过对租户虚拟机进行速率限制来解决这个问题，并且该机制应该尽可能靠近源虚拟机以抑制发送速率。从而避免后续所有转发组件出现拥塞和丢包。
我们处理 VM Tx 和 VM Rx 方向拥塞的方法如下。首先，预处理器将通过监测两个方向的HS-ring水位来判断是否会发生拥塞。在VM Tx方向，Pre-Processor会减慢从对应VM的队列（virtio队列和HS-ring之间有映射关系）取包的速率，形成反压，降低发送速率。来宾操作系统。在VM Rx方向，多种机制需要协同工作。我们在预处理器中实现了基于mac的VM级预分类器，以区分“嘈杂的邻居”并对它们进行速率限制，这可以为其他人提供性能隔离。同时，目标主机上的AVS会通知源AVS对确切的源VM形成反压。
**推迟 SmartNIC 上的 TSO、UFO 和校验和操作。**目前，vNIC提供了一系列丰富的卸载操作，例如TSO、UFO、VM的校验和等。当然，一旦硬件模块从 virtio 队列接收到数据包，它们就应该被处理（参见图 17 中的 ➀）。然而，在我们的部署中，我们发现处理图17中➀位置的TSO和UFO无法避免后续处理中的碎片操作。例如，当数据包大于路径MTU时，需要重新分片。因此，我们建议将这些 I/O 卸载操作（例如 TSO 和 UFO）推迟到后处理器（参见图 17 中的 ➁）。一方面，它可以缓解PPS压力，在软件AVS中获得更大的带宽，因为如此大的数据包只需要一次“匹配动作”操作。另一方面，片段和段模块可以集中实现，以节省硬件资源。
图17.我们应该推迟TSO/UFO和其他vNIC卸载操作的原因。
**在 Triton 中实现可靠传输。**在云数据中心支持多路径和可靠传输已成为一种趋势，但这需要新的覆盖协议，例如SRD [60]、solar [45]和falcon [20]。这些新的覆盖协议对 vSwitch 提出了挑战，因为 vSwitch 应该能够在网络结构中切换路径并在数据包丢失后重新传输数据包。所有这些能力都依赖于特定协议栈的支持。然而，在“Sep-path”架构下，具有独立转发能力的硬件数据路径来实现如此复杂的协议栈行为是不现实的。我们发现这对Triton来说是一个机会，因为统一数据路径中的软件AVS需要处理所有数据包，使其更适合部署覆盖协议栈以实现可靠传输。一种可行的做法是在AVS中添加一个协议栈处理模块，记录每个数据包的RTT和序列，并在必要时触发重传和路径切换行为。
在云之外部署 Triton。 Triton是一种与AVS的定制处理逻辑解耦的硬件卸载架构。工作负载分配方法和优化都可以在其他vSwitch上轻松实现。对于硬件平台，Triton对SmartNIC上的硬件类型没有具体要求。Tofino、FPGA 和其他 ASIC 都足以在 Triton 中实现预处理器和后处理器。虽然我们基于FPGA构建它，但这并不是最具成本效益的方法。或者，某些硬件（例如 eASIC）可以实现更高的性能和更低的成本。
**通过 Triton 支持 ~Tbps 级带宽以进行大规模机器学习。**无论硬件路径还是软件路径，带宽最终都受到 PCIe 总线的限制。凭借巨型帧和 HPS 支持，Triton 可以在单个 SmartNIC 上实现高达 200 Gbps 的带宽。通过多个SmartNIC的水平扩展，Triton足以在单个物理服务器上支持~Tbps级别的带宽和更高的PPS。而且，随着RDMA协议栈在Triton的软件部分很容易实现，将满足大规模机器学习的大带宽和低延迟的要求。
8.2 经验教训
**明确硬件功能的边界。**我们希望本文能够引起人们对软件和硬件之间差距的关注。并非所有工作负载都可以卸载到硬件，挑战硬件边界可能会带来无尽的操作问题。以最常见的TSO和UFO功能为例，一些不常见的数据包，例如带有扩展报头的IPv6数据包和带有填充数据的数据包，可能不适合硬件分片和分段。因此，我们建议澄清硬件功能的边界，并始终提供故障转移方法，以便在硬件无法处理工作负载时回滚到软件。
**建立软硬件一体化测试体系。**为了弥补软硬件研发团队之间的知识鸿沟和信息失真，我们组建了专门的测试团队，对整个系统进行全面的测试，包括全配置压力测试、性能测试和功能测试。这些测试显着增强了AVS的稳定性。
实时升级是可维护性的手段。 AVS需要实时升级能力来快速迭代功能特性。由于云 vSwitch 是每个主机的组件，因此部署任务非常艰巨。我们每天都会进行实时升级以修复错误并支持新功能。除了路由表项的同步之外，我们还需要特别注意新旧AVS进程切换过程中的网络“停机”情况。对于每个物理或虚拟接口的队列，每次只有一个 AVS 进程可以发送/接收数据包。为了避免流量中断，我们依靠预处理器中的流量镜像将数据包发送到新旧 AVS 进程以进行“matchaction”。这样，无论新旧AVS进程切换前后，都有一个特定的AVS进程为虚拟机转发报文。根据我们的运行记录，p999虚拟机的“停机时间”已缩短至100毫秒。
**SmartNIC上的资源调度更快、更灵活。**如今，网络、存储、计算等云Hypervisor服务均部署在SmartNIC（又称DPU、IPU、CIPU等）上，资源（如CPU核、内存）始终不足。但同时，我们也观察到这些虚拟机管理程序服务很少同时达到峰值使用。因此，我们为所有虚拟机管理程序服务实施了动态资源分配策略。
**注重数据可视化。**我们在硬件和软件上都进行了各个阶段的全面数据收集，包括日志、流量统计和其他相关指标。收集到的数据将在分析系统中定期更新，以帮助我们定位网络问题并改进我们的系统。例如，通过这些统计数据，我们的监控系统可以提供任意时刻云网络中一对端点的拓扑图，以及网络链路中每个转发节点的状态。然而，由于“Sep-path”中的硬件资源有限，我们无法完成硬件数据路径中的所有数据收集任务（例如收集每个流的RTT、协议、syn/rst/fin 和其他特殊统计数据）。好消息是，Triton 带来了收集细粒度流量统计数据和制定更精准运营策略的希望。
**供应商和租户可以协调运营和维护。**在主机网络中，某些故障或问题无法仅通过供应商端执行恢复操作来避免，例如virtio队列挂起，需要VM重置设备。我们为租户提供了尽可能多的 vNIC 统计数据或事件以供操作，这已被证明可以使故障转移更加高效。在技术层面，我们正在通过virtio社区推广数字化能力，使云供应商能够向基于virtio设备的虚拟机内部的租户披露尽可能多的网络统计数据和事件。
9 相关工作
vSwitch 的硬件卸载架构。 Agilio CX [4] 和 Broadcom Stingray SmartNIC [7] 可以使用 SoC CPU 内核来运行软件 vSwitch，但无法维持不断增长的带宽。一些纯硬件方案 [28,40,41,49] 专注于将状态数据包处理管道卸载到硬件。这些方案非常消耗资源并且支持的操作很少。此外，它们的灵活性受到合成能力的限制，使其不适用于云。以AccelNet [37]、ASAP2 [6]为代表并在[5,9,12]中工作的“Sep-path”架构采用基于管道的可编程FPGA或集成到NIC中的嵌入式交换机（eSwitch）来实现之间的虚拟交换虚拟网卡。这种硬件集成使他们能够卸载大部分数据包处理操作，从而实现高峰值性能。然而，这种方法无法保证短期连接场景和其他不可卸载场景中的 SLA。另一方面，Triton是对“Sep-path”架构的改进，通过统一的数据路径确保SLA，使AVS能够在保持灵活性的同时实现高性能。本文主要关注云vSwitch的卸载加速架构，特别是SmartNIC内分组数据路径的部署形式。讨论不包括卸载策略、卸载编程系统、相关的特定领域语言或工具链。
**针对特定应用的硬件优化。**先前的工作已经针对 NFV 优化了 NIC。 nicmem [48] 和 RIBOSOME [59] 建议头部有效负载切片可用于浅层 NF 以提高性能。 Triton 使用类似的机制并改进了超时机制，以避免因处理速度差异问题而导致缓冲区耗尽。 Backdraft [58] 指出，当 NIC 队列数量很大（超过 1K）时，使用用户空间驱动程序不可避免地会产生轮询开销（每个队列 100 个 CPU 周期）。 Backdraft 设计了 Doorbell Queues 来解决上述问题，但也会引入延迟。在Triton中，我们使用硬件将大量的virtio队列聚合到HS环中（HS环的数量固定为CPU核心的数量）以减少延迟，从而更加高效。 Reframer [38]展示了聚合流级数据包以改善数据包环形缓冲区中的内存局部性的巨大好处。我们已经在 Triton 中证明了如何通过硬件辅助来放大这一优势。
**云网络中的多功能调试和监控。**云厂商之前的工作说明了vSwitch作为云网络运维端点的重要性和复杂性。 Andromeda[33]在vSwitch软件数据路径中设置了灵活的组件，如Tcpdump、Stats导出器、Packet Tracer、Latency Sampler等，以获取实时网络信息。大规模云监控[34,63,64]需要vSwitch软件通过复杂的带内遥测（INT）消息收集端到端链路上的网络信息。一些富有表现力的网络监控工具 [18, 62] 支持在商用硬件上进行 100 Gbps 流量分析，但需要消耗 4~8 个 x86 内核。然而，在“Sep-path”架构中安装这些组件和机制受到限制（例如硬件编程灵活性、硬件资源和 NIC 核心的性能）的阻碍。而Triton则将灵活、动态的工作负载置于软件之上，轻松丰富了调试和故障排除方法。
10 结论与展望
我们推出 Triton，这是云中 AVS 的灵活硬件卸载架构。 Triton 与我们之前的“Sep-path”架构相比，通过统一的数据路径和全面的工作负载分配模型在性能、灵活性和可操作性之间取得了平衡。我们讨论了 Triton 部署过程中面临的挑战以及克服这些挑战所采用的相应技术。 Triton的有效性已经在云内部得到了验证。与“Sep-path”相比，Triton 的 CPS 几乎增加了一倍，并减少了应用程序级长尾延迟。此外，Triton 保持统一的性能指标和灵活性。我们预计 Triton 的专业知识将有利于我们下一代 SmartNIC 的开发，这些智能网卡经过深度定制，具有更高的性能、低功耗和友好的编程。
这项工作不会引起任何道德问题。
