目录

文章目录

• ​​目录​​
• ​​声明​​
• ​​前言​​
• ​​《Adaptable Switch: A Heterogeneous Switch Architecture for Network-Centric Computing》（自适应交换机：用于网络中心计算的异构交换机体系结构）​​

• ​​引言​​
• ​​架构设计​​

• ​​PL 中用户定制处理流程​​
• ​​开发流程​​
• ​​优化​​
• ​​对象​​
• ​​约束​​

• ​​评测​​

• ​​使用案例​​

• ​​实验结果​​
• ​​结论​​
• ​​参考文献​​

声明

论文精度系列文章，是笔者个人对论文内容的私有解读，可能会在部分引用的基础上进行大量的个人理解与阐述，很可能会歪解论文原本的含义，因此推荐读者阅读论文原文，下方会提供地址链接。

前言

• 时间：2020 年 12 月
• 期刊：IEEE Communication Magazine
• 论文：https://ieeexplore.ieee.org/abstract/document/9311937

论文旨在利用 FPGA 芯片作为协处理器，补充现有可编程 ASIC 芯片的不足，给出了 3 个场景（NDP、DISCO、Stateful Firewall）作为例证；一个新兴的范例是采用 SmartNIC 进行以网络为中心的计算（Network-Centric Computing），它在主机的网络接口上引入了特定于用户的处理，进一步解决了网络核心（交换机）中当前专有的处理和计算问题。

以网络为中心的计算可将计算和数据处理从 CPU 卸载到 SmartNIC，以支持不断增长的吞吐量，大数据量和数据中心的信息复杂性。

《Adaptable Switch: A Heterogeneous Switch Architecture for Network-Centric Computing》（自适应交换机：用于网络中心计算的异构交换机体系结构）

引言

在严格的延迟要求下传输海量数据的需求不断增长，并将 CPU 推向了现代数据中心可扩展性的极限。从数据中心到网络接口卡（NIC）的卸载网络堆栈和计算已越来越多地部署在数据中心中[1]。这种方法称为 SmartNIC，它使人们进一步拥抱网络内计算（In-Network Computing）或以网络为中心的计算（Network-Centric Computing），以通过网络卸载计算、存储和其他功能。在本文中，我们提出了一种适应性强的交换机体系结构，以支持网络核心中的用户特定处理和专有协议，以补充主机网络中现有的 SmartNIC。

引入用户定义流量穿越交换机的开创性工作是 OpenFlow 交换机[2]。这个相当不灵活的数据平面后来被开发成为便携式交换机架构（PSA）[3]。可以从独立于编程协议的分组处理器（P4）语言[4]灵活定义和编译 PSA 兼容数据平面目标。PSA 存在一些局限性，这些局限性促使了本文的工作。

首先，PSA 仅在数据包到达和/或离开时触发处理，从而不支持其他事件的操作。例如，在 PSA 中，很难在新颖的数据平面传输协议（NDP）[5]提议中启用控制，在这种提议中，当缓冲区拥塞时，交换机应该做出反应。稍后将在我们的实验中详细介绍 NDP 的一个使用案例。

其次，PSA 在计算操作（例如，代数计算）方面缺乏能力，这阻止了在 PSA 兼容交换机上部署许多算法。稍后将讨论一个利用复杂计算的流量统计方法（折扣计数，DISCO [6]）的具体示例。

第三，PSA 最初是为对网络数据包进行无状态处理而设计的。PSA 通常很难基于历史状态进行状态协议处理和/或状态计算。为了更好地理解这一点，稍后将讨论防火墙[7]用例。

PSA 非常适合无状态和基于转发的数据平面，但是我们的目标远不止 PSA 的范围：我们的目标是设计一种交换架构，以将计算量卸载和分解到网络中。在语言级别，P4 的最新版本（P4_16）引入了 P4_extern 的概念，以描述该语言的标准格式不支持的任何功能。但是，没有灵活的交换机体系结构具有匹配的 PSA_extern 用于由 P4_extern 定义的处理。解决方案始终是在添加新的 P4_extern 时具有新的专用硬件目标。但是，这与 PSA 作为便携式可编程数据平面的最初思想相冲突，应该避免。

我们通过提出一种异构硬件交换机体系结构来进行创新，以支持任何可能的 P4_extern 定义的处理。我们将此架构命名为自适应交换机，我们已经解决了两个技术挑战，这是我们的主要贡献。第一个是自适应交换机的异构硬件体系结构设计。第二个是如何基于自适应开关以最佳方式开发程序并将其映射到目标。据我们所知，这是第一个开关架构，既提供现场可编程门阵列（FPGA）级别的可编程性，又达到与切换专用集成电路（ASIC）相当的吞吐量。借助提出的自适应交换机体系结构，我们可以消除对 P4 兼容 ASIC 芯片的限制，并支持事件触发，复杂的算术计算和状态处理，所有这些都以线路速率实现。为了评估我们的建议，我们在一个可适配交换机的原型上实现了三个用例，并在评估部分与其他可编程数据平面进行了比较。

架构设计

图 1 是自适应交换机的硬件架构的框图。它由固定交换系统（SS）部分和用户可编程逻辑（PL）部分组成。SS 部分实现了标准交换功能，而 PL 部分则部署了 FPGA 以对定制处理进行编程。所提出的体系结构中的 SS 和 PL 这两个部分可以通过两芯片方法来实现，其中 SS 可以是具有或不具有 P4 兼容性的传统交换 ASIC，PL 可以是 FPGA 芯片，即片上多处理器系统（MPSoC）或将 FPGA 与其他处理器（例如 ARM 内核）集成在单个 SoC 中的自适应计算加速平台（ACAP）芯片。在两芯片解决方案中，两个物理上分离的芯片使用 PCle 或以太网接口或收发器连接。或者，我们还可以用一个高带宽片上总线（如 AXI）来实现单芯片的解决方案。

SS 中的交换结构通常采用交叉开关在入口和出口之间进行高速交换。来自网络接口的数据包在交换矩阵之前/之后经过入口/出口管道。在入口或出口管道中，通常有解析器（提取感兴趣的标头字段），流表（与提取的标头匹配以执行操作），解析器（重组或/和操作数据包）和流量管理器（缓冲区管理，数据包调度，整形等）。

所有传入的数据包都首先进入 SS，并且大多数数据包完全在 SS 中处理。只有那些依赖于 SS 不支持的功能的分组才会被进一步发送给 PL 进行协同处理。在数据包触发 PL 中的处理的情况下，SS 将数据包存储在片上或片外存储器中，并将专用元数据发送到 PL。自定义元数据以承载从 PL 中进行处理所需的数据包中提取的信息。PL 中的处理将更新元数据并将其返回给 SS。SS 将原始数据包与返回的元数据合并为一个完整的数据包以进行转发，或者只是丢弃该数据包。

我们引入了一个额外的内存管理单元（MMU），如图 1 所示。MMU 管理内存以缓冲等待 PL 更新元数据的数据包。更具体地说，它包括三个主要功能：

1. 动态分配存储块以存储数据包。
2. 将数据包数据写入内存。
3. 从内存中读回存储的数据包数据，并使用从PL返回的元数据组装输出数据包。

我们基于两个观察或假设来设计自适应交换机体系结构。

1. PL 中的大多数处理通常仅基于数据包头或/和有效载荷中前几个字节的数据包段。我们的设计仅交换可以灵活定义的元数据，从而保证了 SS 和 PL 之间有限的互连带宽消耗。在极少数情况下，查看整个数据包的处理将用整个数据包填充元数据。
2. 并非所有流量都需要在 PL 中进行处理：否则，相关功能将成为现成交换 ASIC 的一部分，或者直接转移到自适应交换体系结构中的 SS 部分。

考虑到平均数据包长度约为 600B，并且假设元数据大小为 64B，如果通过 PCle Gen4*16 进行接口连接，则在不牺牲端口密度的情况下，即使使用最大的交换，也可以在 PL 中进一步处理 20％ 的流量以 12Tb/s 作为 SS 的 ASIC。在两芯片解决方案中，允许 10％ 的端口密度连接 SS 和 PL，同样，在平均数据包长度为 600B，元数据为 64B 的情况下，所有原始流量可以在 PL 中进行进一步的处理。

PL 中用户定制处理流程

为了有效地映射 PL 中基于用户特定数据流的计算，我们引入了微并行处理流水线，如图 1 右侧。我们将每个处理阶段抽象为一个基本处理单元（BPU）。通过将输入流量负载分配给多个执行引擎，还为每个 BPU 引入了并行性。执行引擎由操作模块组成，该模块对保存在内存中的一组数据进行操作。在通用 BPU 抽象中，到 BPU 的输入（数据流）数量与其前身的执行引擎数量相同，但对于一个 BPU 中的输入和输出数量而言，不一定相同。

数据拆分的优化问题是 NP 难题，可以从多项式时间的平均除法问题中减少。遵循模拟退火算法解决平均分割问题的思想，我们开发了一种启发式算法，用于将与流程相关的处理相关数据映射到每个执行引擎中。

在本节的其余部分，我们将回答有关此 PL 体系结构的两个问题：

1. 如何为 BPU 开发操作模块以适合特定于用户的 PL。
2. 如何在每个 BPU 中正确地填充数据内存，以便调度模块可以尽可能均匀地分配流量负载，从而最终最大化处理吞吐量。

开发流程

我们使用 Xilinx P4-SDNet[8] 作为开发流程的基础来构建我们的原型，如图 2 所示。P4-SDNet 是一种现成的商用产品（COTS），涵盖了从 P4 语言到 SDNet 规范，再到基于 FPGA 的数据平面的编译工具链。P4-SDNet 产品的最新版本支持 P4_16，提供了两个内置的 P4_externs。内置的 P4_externs 支持通过使编译器前端能够识别高级描述来展示将编译器扩展到更多用户特定处理的方法。另外，我们在编译器后端使用注释，这些注释将转换为适当的中间表示（IR）（例如 SDNet[9]），最后映射到 PL。一般而言，对于用户特定的 PL，还可以使用硬件描述语言（Verilog HDL，VHDL 等）进行编码，然后编译为 BPU 和 PL 中的处理管道，这是另一种选择。

优化

如前所述，BPU 中的调度模块将流量负载分配给 BPU 中的多个执行引擎。稻草人解决方案将所有与处理相关的数据复制到每个执行引擎，这通过以循环方式分配流量负载来简单地实现大吞吐量。但是，每个执行引擎中数据存储器的大小是有限的，不足以容纳处理相关数据的完整副本。由于这个原因，通过回答在每个执行引擎中保留完整处理相关数据的哪个子集来解决数据拆分和分配问题并非易事。目的是通过平衡每个执行引擎中处理的工作量来最大化并行处理吞吐量。不失一般性，我们使用流表来保持对相关数据的处理，并将其表示为一种优化问题。

对象

最大程度地增加可发送到每个执行引擎的工作量。

约束

• 约束处理：单个执行引擎具有最大吞吐量，无法将更多的负载分派到达到容量限制的执行引擎。
• 流关联约束：来自同一流的所有数据包应该由同一处理流水线的同一执行引擎处理，以保持处理依赖关系，避免出现无序问题。
• 调度约束：流的处理只能调度到执行引擎（其中一个），在该执行引擎中分配要处理该流的数据（例如，执行引擎中的流表具有该流的信息条目）。
• 内存大小约束：如果数据存储器的大小小于完整处理相关数据，则只能将完整数据的一部分（例如流表）放入执行引擎中。引入更多的数据副本可以减轻数据访问冲突，但需要更多的（片上）内存，因此流可能在执行引擎之间具有冗余性。

数据分割的优化问题是 NP 难问题，可以从多项式时间内的平均分割问题中得到简化[10]。根据模拟退火算法求解平均分割问题的思想，我们开发了一种启发式算法，用于将与处理相关的流数据映射到每个执行引擎中。我们介绍了该算法的主要思想；有关详细信息，请参阅 Github 网站[10]上的代码。

首先，我们使用散列函数将流拆分为多个组；每个组的处理相关数据少于执行引擎可以承载的数据（数据大小约束）。请注意，如果流的汇总工作负载需要多个执行引擎（处理约束），则有包含相同组的执行引擎。其次，我们首先将流组映射到不同的执行引擎中，而不破坏约束。第三，以迭代的方式，我们通过将一个流组从一个源执行引擎随机移动到另一个目标引擎来调整流组分配到执行引擎。执行引擎的工作负载越多，它将流组移出的概率就越大；而选择移动组的目标执行引擎的概率与执行引擎的工作负载成反比。如果通过约束检查的调整能够改进对目标的评估，那么它将以很大的概率被接受（为了跳出局部搜索陷阱，并不总是接受）。在找到足够好的解决方案或达到预设的迭代轮数后，调整迭代停止。

在实际应用中，作为启发式算法输入的流量分布随着时间的推移而变化，因此使用远程控制器来收集执行引擎之间的工作负载变化，作为运行时重新计算和配置的反馈。算法的计算时间评估如下。

评测

我们已经在 Xilinx ZC706 开发板上实现了自适应开关的原型，其中包含 4000 余行代码，包括 SS 函数，PL 映射优化算法和 PL 中的三个用例。可以在 Github[10] 上访问测试代码，在开发过程中我们引用了 NetFPGA 使用的 P4-SDNet 工具集的代码库。我们利用五种跟踪进行评估，包括从 ISP 主干收集的一条真实 ISP 跟踪，从 LTE 基站收集的一条 LTE 跟踪，以及按照跟踪名称指示的分布的三种综合跟踪（指数跟踪，帕累托跟踪和统一跟踪）。

使用案例

• 拥塞控制：NDP [5] 确保在交换机中检测到拥塞时小批量数据包的低转发延迟。NDP 是事件驱动处理的一个示例，现有交换机无法很好地支持它。为了在自适应交换机中部署 NDP，我们在 SS 部分的 MMU 中分配逻辑输出队列。PL 中实现了两种 NDP 操作：一种监视队列深度作为拥塞触发信号，另一种发送显式通知以调整数据包大小。前端编译器将用户逻辑包装到操作模块中，以生成 BPU 和处理管道。
• 网络测量：DISCO [6 ]是一种有效的流量统计算法，但是由于缺乏指数和对数计算支持，因此在（P4 或非 P4）COTS 交换机中部署 DISCO 颇具挑战性。在我们的自适应交换机上的 DISCO 实现中，PL 的输入元数据包括流 ID 和每个传入数据包的长度，而输出是保存在片上存储器中的流统计计数器值。我们使用 Verilog HDL 为 DISCO 实现 P4_extern 函数。
• 有状态防火墙：我们还提供了一个有状态防火墙[11]转发引擎，其形式为可适配交换机支持的 P4_extern 功能，这对商品交换机是一个挑战。实现的引擎记录用于过滤数据包的连接状态。实现了两个硬件流表：一个用于基本匹配操作，另一个存储每个相应流的状态列表。当来自流的数据包到达时，它根据当前流状态和感兴趣的数据包字段执行操作。它还更新匹配操作表以指示下一个状态。

实验结果

我们量化了原型的五种硬件资源消耗。查找表（LUT）用作组合逻辑实现。LUT 随机存取存储器（LUT RAM）是用于缓存短变量值的寄存器资源。触发器（FF）电路单元可以由时钟信号驱动，以建立时序逻辑。Block RAM（BRAM）是片上大型存储单元。数字信号处理器（DSP）是分布式快速单时钟周期数学计算核心。

在表 1 中，我们展示了当我们为每个用例启用一个分派和 20 个执行引擎时的结果。表中的结果以 “数量/比例” 的形式显示，其中我们显示了实现原型的 FPGA 的确切消耗量和占总资源的比例。Dispatch 同时考虑了 20 个解析器（SDNet 生成）和一个 2020 交换机（具有 20 个均衡器体系结构）的消耗，以将流量负载分配给执行引擎。

对于这三个 Case，每个执行引擎都包含一个精确匹配表（200 个条目）作为数据存储（在实践中可以根据需求和硬件容量进行调整）。在拥塞控制用例中，对于拥塞控制用例，有 20 个输出端口的 40 个优先级队列，每个端口的队列大小为 64kB。此外，我们还部署了 20 个计数引擎，在测量情况下总共有 4k 计数器，在防火墙情况下有 20 个可编程状态转换表。随着使用的执行引擎、阶段、管道和条目数量的增加，资源消耗几乎呈线性增加。从结果中，我们观察到一个典型的 FPGA 足以部署这三个用户案例。

图 3 中，我们描述了增加执行引擎数量时的吞吐量趋势。我们根据最大频率、数据总线宽度和平均数据包大小（600b）计算吞吐量。使用更多的执行引擎时，最大频率会下降，而使用 20 个以上的执行引擎时，吞吐量增益会变得平缓。我们观察到，对于拥塞控制和测量用例，原型最多达到 8tb/s 左右，对于有状态防火墙用例，原型最多达到 6tb/s 左右的吞吐量。

通过查看每个用例所需的周期，我们将拥塞控制、网络测量和防火墙用例的 PL 处理延迟分别确定为 0.130ms、0.136ms 和 0.142ms。

我们还使用 300 多行 Python 代码在运行时进行配置来实现 PL 映射优化，并使用 PyPy 工具集将其部署在 Dell R620 服务器（具有 8G RAM 和运行 Ubuntu 16.04 LTS OS 的 2.80 GHz 四核 Intel CPU）中。和即时（JIT）编译器来加速 Python 程序。

图 4 绘制了本节前面介绍的五个流量跟踪下的平均计算时间。共有五个烛台组，分别代表执行引擎（具有一个阶段和一个处理管道）数量的不同设置，即 K = 4、8、12、16 和 20 个执行引擎。K 值较大时，运行时映射优化需要花费较长时间。使用 20 个执行引擎，在我们测试的所有跟踪下，计算时间不到 8.30s，置信度为 95％。

表 2 总结了各种常见可编程数据平面的特征，例如，基于软件的交换机[12]、基于 FPGA 的交换机[13]和基于 P4 兼容交换 ASIC 的交换机[14]。在介绍[11]中，我们提到了很多基于事件驱动的 ASIC 和基于触发的 ASIC 的特性，而在介绍[11]中，我们提到了基于事件驱动的 ASIC 和基于触发的 ASIC 的特性。所提出的可适应性交换机将其自身定位在设计空间中，具有与基于纯软件/FPGA 的交换机相似的可编程性和与 P4 兼容 ASIC 相当的（稍微低一点）吞吐量。

结论

我们提出了一种适用于网络中心计算的自适应交换体系结构。Adaptive switch 背后的关键是利用交换系统提供高吞吐量，同时将硬件可编程处理卸载到 FPGA 上。我们已经实现了一个原型和三个用例。

实验表明，该结构的灵活性优于现有的固定功能交换机。此外，所实现的设计可以很好地控制资源消耗，以每秒数太比特的速率提供处理吞吐量。尽管 PL 部分的处理吞吐量仍然小于交换 ASIC 的吞吐量，但是我们认为，整个分组或所有数据流都不需要在 PL 中使用用户定义的处理来处理，因此，自适应交换体系结构具有与 COTS 交换机兼容的总吞吐量。

参考文献

[1] G. Lu et al., “Serverswitch: A Programmable and High Performance Platform for Data Center Networks,” Proc. 2011 USENICS NSDI, Boston,MA, vol. 11, 2011.

[2] N. McKeown et al., “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM CCR, vol. 38, no. 2, 2008,pp. 69–74.

[3] P4.org Architecture WG, “Portable Switch Architecture (PSA),” Nov. 2018; https://p4.org/p4-spec/docs/PSA-v1.1.0.html, accessed July 15, 2020.

[4] P. Bosshart et al., “P4: Programming Protocol-Independent Packet Processors,” ACM SIGCOMM CCR, vol. 44, no. 3, 2014, pp. 87–95.

[5] M. Handley et al., “Re-Architecting Datacenter Networks and Stacks for Low Latency and High Performance,” Proc. 2017 ACM SIGCOMM, Los Angeles, CA, 2017, pp. 29–42.

[6] C. Hu et al., “Disco: Memory Efficient and Accurate Flow Statistics for Network Measurement,” Proc. 2010 IEEE ICDCS, Genova, Italy, 2010, pp. 665–74.

[7] S. Zerkane et al., “Software Defined Networking Reactive Stateful Firewall,” Proc. 2016 IFIPSEC, Ghent, Belgium, 2011, pp. 119–32.

[8] Xilinx, “User Guide: P4-SDNet Translator,” Jan. 2017; https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug1…, accessed July 15, 2020.

[9] Xilinx, “User Guide: SDNet Packet Processor,” Jan. 2017; https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/UG1…, accessed July 15, 2020.

[10] S. Qiao et al., “Testing Code of Adaptable Switch Project,” Sept. 2020; https://github.com/Adaptable-Switch/AS_test/, accessed Sept. 21, 2020.

[11] S. Pontarelli et al., “Flowblaze: Stateful Packet Processing in Hardware,” Proc. 2019 USENICS NSDI, Boston, MA, 2019, pp. 531–48.

[12] M. Shahbaz et al., “Pisces: A Programmable, Protocol-Independent Software Switch,” Proc. 2016 ACM SIGCOMM, Florianopolis, Brazil, 2016, pp. 525–38.

[13] H. Wang et al., “P4FPGA: A Rapid Prototyping Framework for p4,” Proc. 2017 ACM SOSR, Santa Clara, CA, 2017, pp.122–35.

[14] P. Bosshart et al., “Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN,” ACM SIGCOMM CCR, vol. 43, no. 4, 2013, pp. 99–110.

[15] S. Ibanez et al., “Event-Driven Packet Processing,” Proc. 2019 ACM HOT NETS, Princeton, NJ, 2019, pp. 133–40.