一文详解DPU架构

优化
如前所述，BPU中的调度模块将流量负载分配给BPU中的多个执行引擎。稻草人解决方案将所有与处理相关的数据复制到每个执行引擎，这通过以循环方式分配流量负载来简单地实现大吞吐量。但是，每个执行引擎中数据存储器的大小是有限的，不足以容纳处理相关数据的完整副本。由于这个原因，通过回答在每个执行引擎中保留完整处理相关数据的哪个子集来解决数据拆分和分配问题并非易事。目的是通过平衡每个执行引擎中处理的工作量来最大化并行处理吞吐量。不失一般性，我们使用流表来保持对相关数据的处理，并将其表示为一种优化问题。
对象
最大程度地增加可发送到每个执行引擎的工作量。
约束
约束处理
单个执行引擎具有最大吞吐量，无法将更多的负载分派到达到容量限制的执行引擎。
流关联约束
来自同一流的所有数据包应该由同一处理流水线的同一执行引擎处理，以保持处理依赖关系，避免出现无序问题。
调度约束
流的处理只能调度到执行引擎（其中一个），在该执行引擎中分配要处理该流的数据（例如，执行引擎中的流表具有该流的信息条目）。
内存大小约束
如果数据存储器的大小小于完整处理相关数据，则只能将完整数据的一部分（例如流表）放入执行引擎中。引入更多的数据副本可以减轻数据访问冲突，但需要更多的（片上）内存，因此流可能在执行引擎之间具有冗余性。
数据分割的优化问题是NP难问题，可以从多项式时间内的平均分割问题中得到简化[10]。根据模拟退火算法求解平均分割问题的思想，我们开发了一种启发式算法，用于将与处理相关的流数据映射到每个执行引擎中。我们介绍了该算法的主要思想；有关详细信息，请参阅github网站[10]上的代码。首先，我们使用散列函数将流拆分为多个组；每个组的处理相关数据少于执行引擎可以承载的数据（数据大小约束）。请注意，如果流的汇总工作负载需要多个执行引擎（处理约束），则有包含相同组的执行引擎。其次，我们首先将流组映射到不同的执行引擎中，而不破坏约束。第三，以迭代的方式，我们通过将一个流组从一个源执行引擎随机移动到另一个目标引擎来调整流组分配到执行引擎。执行引擎的工作负载越多，它将流组移出的概率就越大；而选择移动组的目标执行引擎的概率与执行引擎的工作负载成反比。如果通过约束检查的调整能够改进对目标的评估，那么它将以很大的概率被接受（为了跳出局部搜索陷阱，并不总是接受）。在找到足够好的解决方案或达到预设的迭代轮数后，调整迭代停止。
在实际应用中，作为启发式算法输入的流量分布随着时间的推移而变化，因此使用远程控制器来收集执行引擎之间的工作负载变化，作为运行时重新计算和配置的反馈。算法的计算时间评估如下。
3. 评测
我们已经在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功能，这对商品交换机是一个挑战。实现的引擎记录用于过滤数据包的连接状态。实现了两个硬件流表：一个用于基本匹配操作，另一个存储每个相应流的状态列表。当来自流的数据包到达时，它根据当前流状态和感兴趣的数据包字段执行操作。它还更新匹配操作表以指示下一个状态。
4. 实验结果
我们量化了原型的五种硬件资源消耗。查找表（LUT）用作组合逻辑实现。LUT随机存取存储器（LUT RAM）是用于缓存短变量值的寄存器资源。触发器（FF）电路单元可以由时钟信号驱动，以建立时序逻辑。Block RAM（BRAM）是片上大型存储单元。数字信号处理器（DSP）是分布式快速单时钟周期数学计算核心。
在表1中，我们展示了当我们为每个用例启用一个分派和20个执行引擎时的结果。表中的结果以“数量/比例”的形式显示，其中我们显示了实现原型的FPGA的确切消耗量和占总资源的比例。dispatch行同时考虑了20个解析器（SDNet生成）和一个2020交换机（具有20个均衡器体系结构）的消耗，以将流量负载分配给执行引擎。对于这三个case行，每个执行引擎都包含一个精确匹配表（200个条目）作为数据存储（在实践中可以根据需求和硬件容量进行调整）。在拥塞控制用例中，对于拥塞控制用例，有20个输出端口的40个优先级队列，每个端口的队列大小为64 kB。此外，我们还部署了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.30 s，置信度为95％。

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

5. 结论
我们提出了一种适用于网络中心计算的自适应交换体系结构。Adaptive switch背后的关键是利用交换系统提供高吞吐量，同时将硬件可编程处理卸载到FPGA上。我们已经实现了一个原型和三个用例。实验表明，该结构的灵活性优于现有的固定功能交换机。此外，所实现的设计可以很好地控制资源消耗，以每秒数太比特的速率提供处理吞吐量。尽管PL部分的处理吞吐量仍然小于交换ASIC的吞吐量，但是我们认为，整个分组或所有数据流都不需要在PL中使用用户定义的处理来处理，因此，自适应交换体系结构具有与COTS交换机兼容的总吞吐量。