网络数据包的实时GPU处理方案原理解析

网络数据包的实时GPU处理方案原理解析网络数据包的实时GPU处理是一种适用于几个不同应用领域的技术，包括信号处理、网络安全、信息收集和输入重建。这些应用程序的目标是实现一个内联数据包处理管线（Pipeline），以在GPU内存中接收数据包（无需通过CPU内存暂存副本）；与一个或多个CUDA内核并行地处理它们；然后运行推断、评估或通过网络发送计算结果。通常，在这个管线中，CPU是协调人，因为它必须使网卡（NIC）接收活动与GPU处理同步。一旦GPU内存中接收到新的数据包，这将唤醒CUDA内核。类似的方法也可以应用于管线的发送侧。图1.以CPU为中心的应用程序，CPU协调GPU和网卡工作数据平面开发套件（DPDK）框架引入了goudev库

来为此类应用提供解决方案：使用GPU内存（GPUDirectRDMA技术）结合低延迟CPU同步进行接收或发送。

01

GPU发起的通信从图1中可以看出，CPU是主要瓶颈。它在同步NIC和GPU任务以及管理多个网络队列方面承担了太多的责任。例如，考虑一个具有多个接收队列和100Gbps传入流量的应用程序。以CPU为中心的解决方案将具有：CPU调用每个接收队列上的网络功能，以使用一个或多个CPU核心接收GPU存储器中的数据包CPU收集数据包信息（数据包地址、编号）CPU向GPU通知新接收的数据包GPU处理数据包这种以CPU为中心的方法是：资源消耗：为了处理高速率网络吞吐量（100Gbps或更高），应用程序可能需要专用整个CPU物理核心来接收（和/或发送）数据包不可扩展：为了与不同的队列并行接收（或发送），应用程序可能需要使用多个CPU核心，即使在CPU核心的总数可能被限制在较低数量（取决于平台）的系统上也是如此平台依赖性：低功耗CPU上的同一应用程序将降低性能GPU内联分组处理应用程序的下一个自然步骤是从关键路径中删除CPU。移动到以GPU为中心的解决方案，GPU可以直接与NIC交互以接收数据包，因此数据包一到达GPU内存，处理就可以开始。同样的方法也适用于发送操作。GPU从CUDA内核控制NIC活动的能力称为GPU发起的通信。假设使用NVIDIAGPU和NVIDIANIC，则可以将NIC寄存器暴露给GPU的直接访问。这样，CUDA内核可以直接配置和更新这些寄存器，以协调发送或接收网络操作，而无需CPU的干预。图2.以GPU为中心的应用程序，GPU控制网卡和数据包处理，无需CPU根据定义，DPDK是CPU框架。要启用GPU发起的通信，需要在GPU上移动整个控制路径，这是不适用的。因此，通过创建新的NVIDIADOCA库来启用此功能。

02

NVIDIADOCAGPUNetIO库NVIDIADOCASDK是新的NVIDIA框架，由驱动程序、库、工具、文档和示例应用程序组成。需要这些资源通过利用NVIDIA硬件可以在主机系统和DPU上可用的网络、安全性和计算功能来支持应用程序。NVIDIADOCAGPUNetIO是在NVIDIADOCA1.5版本的基础上开发的一个新库，用于在DOCA生态系统中引入GPU设备的概念（图3）。为了促进创建以DOCAGPU为中心的实时数据包处理应用程序，DOCAGPUNetIO结合了GPUDirectRDMA用于数据路径加速、智能GPU内存管理、CPU和GPU之间的低延迟消息传递技术（通过GDRCopy功能）和GPU发起的通信。这使CUDA内核能够直接控制NVIDIAConnectX网卡。为了最大化性能，DOCAGPUNetIO库必须用于GPUDirect友好的平台，其中GPU和网卡通过专用PCIe网桥直接连接。DPU融合卡就是一个示例，但同样的拓扑也可以在主机系统上实现。DOCAGPUNetIO目标是GPU数据包处理网络应用程序，使用以太网协议在网络中交换数据包。对于这些应用程序，不需要像基于RDMA的应用程序那样，通过OOB机制跨对等端进行预同步阶段。也无需假设其他对等端将使用DOCAGPUNetIO进行通信，也无需了解拓扑。在未来的版本中，RDMA选项将被启用以覆盖更多的用例。DOCA当前版本中启用的GPUNetIO功能包括：GPU发起的通信:CUDA内核可以调用DOCAGPUNetIO库中的CUDAdevice函数，以指示网卡发送或接收数据包精确的发送调度：通过GPU发起的通信，可以根据用户提供的时间戳来调度未来的数据包传输GPUDirectRDMA：以连续固定大小GPU内存步幅接收或发送数据包，无需CPU内存暂存副本信号量：在CPU和GPU之间或不同GPUCUDA内核之间提供标准化的低延迟消息传递协议CPU对CUDA内存的直接访问：CPU可以在不使用GPU内存API的情况下修改GPU内存缓冲区图3.NVIDIADOCAGPUNetIO是一个新的DOCA库，需要在同一平台上安装GPU和CUDA驱动程序和库如图4所示，典型的DOCAGPUNetIO应用程序步骤如下：CPU上的初始配置阶段：使用DOCA识别和初始化GPU设备和网络设备使用DOCAGPUNetIO创建可从CUDA内核管理的接收或发送队列使用

DOCAFlow

确定应在每个接收队列中放置哪种类型的数据包（例如，IP地址的子集、TCP或UDP协议等）启动一个或多个CUDA内核（执行数据包处理/过滤/分析）CUDA内核内GPU上的运行时控制和数据路径：使用DOCAGPUNetIOCUDA设备函数发送或接收数据包使用DOCAGPUNetIOCUDA设备函数与信号量交互，以使工作与其他CUDA内核或CPU同步图4.由多个构建块组成的通用GPU数据包处理管线数据流以下各节概述了结合DOCAGPUNetIO构建块的可能GPU数据包处理管线应用程序布局。

03

CPU接收和GPU处理第一个示例以CPU为中心，不使用GPU发起的通信功能。它可以被视为以下章节的基线。CPU创建可从CPU自身管理的接收队列，以接收GPU存储器中的数据包，并为每个队列分配流量控制规则。在运行时，CPU接收GPU存储器中的数据包。它通过DOCAGPUNetIO信号量向一个或多个CUDA内核通知每个队列新一组数据包的到达，提供GPU内存地址和数据包数量等信息。在GPU上，CUDA内核轮询信号量，检测更新并开始处理数据包。图5.GPU数据包处理管道，CPU在GPU内存中接收数据包，并使用NVIDIADOCAGPUNetIO信号量通知数据包处理CUDA内核有关传入数据包这里，DOCAGPUNetIO信号量具有类似于DPDKgpudevcommunicationlist的功能，使得CPU接收数据包和GPU在处理这些数据包之前等待接收这些数据包之间能够实现低延迟通信机制。信号量还可用于GPU在包处理完成时通知CPU，或在两个GPUCUDA内核之间共享关于已处理包的信息。该方法可作为性能评估的基准。由于它以CPU为中心，因此严重依赖CPU型号、功率和内核数量。

04

GPU接收和GPU处理上一节中描述的以CPU为中心的管线可以通过以GPU为中心的方法进行改进，该方法使用GPU发起的通信，使用CUDA内核管理接收队列。以下部分提供了两个示例：多CUDA内核和单CUDA内核。

05

多CUDA内核使用这种方法，至少涉及两个CUDA内核，一个专用于接收数据包，另一个专用用于数据包处理。接收器CUDA内核可以通过信号量向第二CUDA内核提供数据包信息。图6.GPU数据包处理管线，CPU在GPU内存中接收数据包，并使用DOCAGPUNetIO信号量通知数据包处理CUDA内核有关传入数据包这种方法适用于高速网络和延迟敏感的应用程序，因为两个接收操作之间的延迟不会被其他任务延迟。期望将接收器CUDA内核的每个CUDA块关联到不同的队列，并行地接收来自所有队列的所有数据包。

06

单CUDA内核通过使单个CUDA内核负责接收和处理数据包，仍然为每个队列专用一个CUDA块，可以简化先前的实现。图7.GPU数据包处理管线，单个GPUCUDA内核接收GPU内存中的数据包并进行数据包处理这种方法的一个缺点是每个CUDA块两个接收操作之间的延迟。如果数据包处理需要很长时间，应用程序可能无法跟上在高速网络中接收新数据包的速度。

07

GPU接收、GPU处理和GPU发送到目前为止，大多数关注点都集中在管线的“接收和处理”部分。然而，DOCAGPUNetIO还可以在GPU上生成一些数据，制作数据包并从CUDA内核发送，而无需CPU干预。图8描述了一个完整的接收、处理和发送管线的示例图8.具有GPUCUDA内核的GPU数据包处理管线在GPU内存中接收数据包，进行数据包处理，最后制作新数据包

08

NVIDIADOCA

GPUNetIO示例应用程序与任何其他NVIDIADOCA库一样，DOCAGPUNetIO有一个专用应用程序，用于API使用参考和测试系统配置和性能。该应用程序实现了前面描述的管线，提供了不同类型的数据包处理，如IP校验和、HTTP数据包过滤和流量转发。以下部分概述了应用程序的不同操作模式。报告了一些性能数据，将其视为可能在未来版本中更改和改进的初步结果。使用两个基准系统，一个用于接收数据包，另一个用于发送数据包，背靠背连接（图9）。运行DOCAGPUNetIO应用程序的接收器是带有NVIDIABlueField-2XDPU融合卡

的DellPowerEdgeR750。该配置为嵌入式CPU模式，因此应用程序使用DPU上的NVIDIAConnectX-6Dx网卡和GPUA100X在主机系统CPU上运行。软件配置为Ubuntu20.04、MOFED5.8和CUDA11.8。发送器是GigabyteIntelXeonGold6240R，其通过PCIeGen3与NVIDIAConnectX-6Dx连接。此计算机不需要任何GPU，因为它运行T-RexDPDKpacketgeneratorv2.99。软件配置为Ubuntu20.04和MOFED5.8。图9.接收器（DellR750）和发送器（Gigabyte）系统背靠背连接到基准NVIDIADOCAGPUNetIO应用程序该应用程序也已在DPUArm内核上执行，导致了相同的性能结果，并证明了以GPU为中心的解决方案与CPU无关。请注意，DOCAGPUNetIO最低要求是具有GPU和具有直接PCIe连接的NIC的系统。DPU并不是严格要求。

09

IP校验和，GPU仅接收应用程序使用GPU发起的通信来创建一个或多个接收队列以接收分数据包。可以使用单CUDA内核或多CUDA内核模式。图10.NVIDIADOCAGPUNetIO应用程序中的第一个管线模式：GPU接收、计算IP校验和并向CPU报告每个数据包都通过简单的IP校验和验证进行处理，只有通过此测试的数据包才算作“好数据包”。通过信号量，好数据包的数量被报告给CPU，CPU可以在控制台上打印报告。通过使用T-Rex数据包生成器以约100Gbps（约11.97Mpps）的速度发送30亿个1KB大小的数据包，并在DOCAGPUNetIO应用程序侧报告相同数量的数据包以及正确的IP校验和，实现了单队列零数据包丢失。相同的配置在BlueField-2融合卡上进行了测试，结果相同，证明了GPU发起的通信是一个独立于平台的解决方案。由于数据包大小为512字节，T-Rex数据包生成器无法发送超过86Gbps（约20.9Mpps）的数据包。即使每秒数据包的数量几乎是两倍，DOCAGPUNetIO也没有报告任何数据包丢失。

10

HTTP过滤，GPU仅接收假设一个更复杂的场景，数据包处理CUDA内核只过滤具有特定特征的HTTP数据包。它将“好数据包”信息复制到第二个GPU内存HTTP数据包列表中。一旦此HTTP数据包列表中的下一个项目充满了数据包，通过专用信号量，过滤CUDA内核就会解除第二个CUDA内核的阻止，从而对累积的HTTP数据包进行一些推断。信号量还可用于向CPU线程报告统计信息。图11.

NVIDIADOCAGPUNetIO应用程序中的第二种管线模式。GPU只接收、过滤HTTP数据包，并通过专用信号量解除阻止CUDA内核对这些数据包进行分析该管线配置提供了复杂流水线的示例，该复杂管线包括多个数据处理和过滤阶段以及诸如AI管线之类的推理功能。

11

流量转发本节介绍如何通过GPU发起的通信使用DOCAGPUNetIO启用流量转发。在每个接收到的数据包中，在通过网络发送回数据包之前，交换MAC和IP源地址和目的地址。图12.NVIDIADOCAGPUNetIO应用程序中的第三种管线模式。GPU接收、交换每个数据包的MAC和IP地址，并发送回修改后的数据包。通过使用T-Rex数据包生成器以~90Gbps的速度发送30亿个1KB大小的数据包，实现了只有一个接收队列和一个发送队列的零数据包丢失。

12

用于5G的NVIDIAAerialSDK决定采用以GPU为中心的解决方案的动机可能是性能和低延迟要求，但也可能是为了提高系统容量。CPU在处理连接到接收器应用程序的越来越多的对等端时可能成为瓶颈。GPU提供的高度并行化可以提供可扩展的实现，以并行处理大量对等端，而不会影响性能。NVIDIAAerial是一个用于构建高性能、软件定义的5GL1堆栈的SDK，该堆栈通过GPU上的并行处理进行了优化。具体而言，NVIDIAAeroSDK可用于构建基带单元（BBU）软件，该软件负责通过无线电单元（RU）发送（下行链路）或接收（上行链路）无线客户端数据帧，该数据帧被拆分为多个以太网数据包。在上行链路中，BBU接收数据包，验证数据包，并在触发信号处理之前重建每个RU的原始数据帧。使用NVIDIAAerialSDK，这在GPU中发生：CUDA内核专用于每个时隙的每个RU，以重建帧并触发GPU信号处理的CUDA内核序列。通过DPDKgpudev库实现了网卡接收数据包以及GPU重新排序和处理数据包的编排（图13）。图13.

NVIDIAAerial5GL1以CPU为中心的架构，带有DPDKgpudev库第一个实现在现代Intelx86系统上仅使用一个CPU内核，就能够以25Gbps的速度保持4个RU的工作速度。然而，随着基站数量的增加，网卡和GPU之间的CPU功能成为瓶颈。CPU按顺序工作。随着单个CPU核心接收和管理越来越多的RU流量，同一RU的两次接收之间的时间取决于RU的数量。对于2个CPU核，每个核在RU的子集上工作，相同RU的两次接收之间的时间减半。然而，这种方法对于越来越多的客户端是不可扩展的。此外，PCIe事务的数量从NIC增加到CPU，然后从CPU增加到GPU（图14）。图14.NVIDIAAerial5G应用程序以CPU为中心的控制流程，连接了多个RU。CPU内核顺序地接收并通知每个连接的RU的GPU重建内核。这不是一种可扩展的方法。为了克服所有这些问题，NVIDIAAerialSDK的以GPU为中心的新版本已通过DOCAGPUNetIO库实现。每个CUDA内核负责在每个时隙重建来自特定RU的数据包，并通过接收能力进行了改进（图15）。图15.以GPU为中心的NVIDIAAerialSDK5G架构，采用NVIDIADOCAGPUNetIO此时，关键路径中不需要CPU，因为每个CUDA内核都是完全独立的，能够并行和实时处理越来越多的RU。这增加了系统容量，并减少了每个时隙处理数据包的延迟和PCIe事务的数量。CPU不必与GPU通信以提供数据包信息。图16.NVIDIAAerial5GSDK以GPU为中心的控制流程，连接了多个RU。这是一种可扩