越来越多的网络应用程序需要进行 GPU 实时数据包处理，以实现高数据率解决方案：数据过滤、数据放置、网络分析、传感器信号处理等。
一个主要动机是 GPU 可以实现并行处理多个数据包的高度并行性，同时提供可扩展性和可编程性。
有关这些技术的基本概念以及基于 DPDK gpudev 库的初始解决方案的概述，请扫描下方二维码参见文章《通过 GPU 使用 DPDK 和 GPUdev 增强内联数据包处理 》。
这篇文章解释了新的 NVIDIA DOCA GPUNetIO 库如何克服以前 DPDK 解决方案中的一些限制，向以 GPU 为中心的数据包处理应用程序迈进了一步。
介绍
网络数据包的实时 GPU 处理是一种适用于几个不同应用领域的技术，包括信号处理、网络安全、信息收集和输入重建。这些应用程序的目标是实现一个内联数据包处理管线（Pipeline），以在 GPU 内存中接收数据包（无需通过 CPU 内存暂存副本）；与一个或多个 CUDA 内核并行地处理它们；然后运行推断、评估或通过网络发送计算结果。
通常，在这个管线中，CPU 是协调人，因为它必须使网卡（NIC）接收活动与 GPU 处理同步。一旦 GPU 内存中接收到新的数据包，这将唤醒 CUDA 内核。类似的方法也可以应用于管线的发送侧。
图 1 . 以 CPU 为中心的应用程序， CPU 协调 GPU 和网卡工作
数据平面开发套件（DPDK）框架引入了 goudev 库来为此类应用提供解决方案：使用 GPU 内存（GPUDirect RDMA 技术）结合低延迟 CPU 同步进行接收或发送。
GPU 发起的通信
从图 1 中可以看出，CPU 是主要瓶颈。它在同步 NIC 和 GPU 任务以及管理多个网络队列方面承担了太多的责任。例如，考虑一个具有多个接收队列和 100 Gbps 传入流量的应用程序。以 CPU 为中心的解决方案将具有：
这种以 CPU 为中心的方法是：
GPU 内联分组处理应用程序的下一个自然步骤是从关键路径中删除 CPU 。移动到以 GPU 为中心的解决方案，GPU 可以直接与 NIC 交互以接收数据包，因此数据包一到达 GPU 内存，处理就可以开始。同样的方法也适用于发送操作。
GPU 从 CUDA 内核控制 NIC 活动的能力称为 GPU 发起的通信。假设使用 NVIDIA GPU 和 NVIDIA NIC ，则可以将 NIC 寄存器暴露给 GPU 的直接访问。这样，CUDA 内核可以直接配置和更新这些寄存器，以协调发送或接收网络操作，而无需 CPU 的干预。
图 2 . 以 GPU 为中心的应用程序，GPU 控制网卡和数据包处理，无需 CPU
根据定义，DPDK 是 CPU 框架。要启用 GPU 发起的通信，需要在 GPU 上移动整个控制路径，这是不适用的。因此，通过创建新的 NVIDIA DOCA 库来启用此功能。
NVIDIA DOCA GPUNetIO 库
NVIDIA DOCA SDK 是新的 NVIDIA 框架，由驱动程序、库、工具、文档和示例应用程序组成。需要这些资源通过利用 NVIDIA 硬件可以在主机系统和 DPU 上可用的网络、安全性和计算功能来支持应用程序。
NVIDIA DOCA GPUNetIO 是在 NVIDIA DOCA 1.5 版本的基础上开发的一个新库，用于在 DOCA 生态系统中引入 GPU 设备的概念（图 3）。为了促进创建以 DOCA GPU 为中心的实时数据包处理应用程序，DOCA GPUNetIO 结合了 GPUDirect RDMA 用于数据路径加速、智能 GPU 内存管理、CPU 和 GPU 之间的低延迟消息传递技术（通过 GDRCopy 功能）和 GPU 发起的通信。
这使 CUDA 内核能够直接控制 NVIDIA ConnectX 网卡。为了最大化性能， DOCA GPUNetIO 库必须用于 GPUDirect 友好的平台，其中 GPU 和网卡通过专用 PCIe 网桥直接连接。DPU 融合卡就是一个示例，但同样的拓扑也可以在主机系统上实现。
DOCA GPUNetIO 目标是 GPU 数据包处理网络应用程序，使用以太网协议在网络中交换数据包。对于这些应用程序，不需要像基于 RDMA 的应用程序那样，通过 OOB 机制跨对等端进行预同步阶段。也无需假设其他对等端将使用 DOCA GPUNetIO 进行通信，也无需了解拓扑。在未来的版本中，RDMA 选项将被启用以覆盖更多的用例。
DOCA 当前版本中启用的 GPUNetIO 功能包括：
图 3 . NVIDIA DOCA GPUNetIO 是一个新的 DOCA 库，需要在同一平台上安装 GPU 和 CUDA 驱动程序和库
如图 4 所示无线网接收器，典型的 DOCA GPUNetIO 应用程序步骤如下：
CPU 上的初始配置阶段：
CUDA 内核内 GPU 上的运行时控制和数据路径：
图 4 . 由多个构建块组成的通用 GPU 数据包处理管线数据流
以下各节概述了结合 DOCA GPUNetIO 构建块的可能 GPU 数据包处理管线应用程序布局。
CPU 接收和 GPU 处理
第一个示例以 CPU 为中心，不使用 GPU 发起的通信功能。它可以被视为以下章节的基线。CPU 创建可从 CPU 自身管理的接收队列，以接收 GPU 存储器中的数据包，并为每个队列分配流量控制规则。
在运行时，CPU 接收 GPU 存储器中的数据包。它通过 DOCA GPUNetIO 信号量向一个或多个 CUDA 内核通知每个队列新一组数据包的到达，提供 GPU 内存地址和数据包数量等信息。在 GPU 上，CUDA 内核轮询信号量，检测更新并开始处理数据包。
图 5 . GPU 数据包处理管道，CPU 在 GPU 内存中接收数据包，并使用 NVIDIA DOCA GPUNetIO 信号量通知数据包处理 CUDA 内核有关传入数据包
这里，DOCA GPUNetIO 信号量具有类似于 DPDK gpudev communication list 的功能，使得 CPU 接收数据包和 GPU 在处理这些数据包之前等待接收这些数据包之间能够实现低延迟通信机制。信号量还可用于 GPU 在包处理完成时通知 CPU ，或在两个 GPU CUDA 内核之间共享关于已处理包的信息。
该方法可作为性能评估的基准。由于它以 CPU 为中心无线网接收器，因此严重依赖 CPU 型号、功率和内核数量。
GPU 接收和 GPU 处理
上一节中描述的以 CPU 为中心的管线可以通过以 GPU 为中心的方法进行改进，该方法使用 GPU 发起的通信，使用 CUDA 内核管理接收队列。以下部分提供了两个示例：多 CUDA 内核和单 CUDA 内核。
多 CUDA 内核
使用这种方法，至少涉及两个 CUDA 内核，一个专用于接收数据包，另一个专用用于数据包处理。接收器 CUDA 内核可以通过信号量向第二 CUDA 内核提供数据包信息。
图 6 . GPU 数据包处理管线，CPU 在 GPU 内存中接收数据包，并使用 DOCA GPUNetIO 信号量通知数据包处理 CUDA 内核有关传入数据包
这种方法适用于高速网络和延迟敏感的应用程序，因为两个接收操作之间的延迟不会被其他任务延迟。期望将接收器 CUDA 内核的每个 CUDA 块关联到不同的队列，并行地接收来自所有队列的所有数据包。
单 – CUDA 内核
通过使单个 CUDA 内核负责接收和处理数据包，仍然为每个队列专用一个 CUDA 块，可以简化先前的实现。
图 7 . GPU 数据包处理管线，单个 GPU CUDA 内核接收 GPU 内存中的数据包并进行数据包处理
这种方法的一个缺点是每个 CUDA 块两个接收操作之间的延迟。如果数据包处理需要很长时间，应用程序可能无法跟上在高速网络中接收新数据包的速度。
GPU 接收、 GPU 处理和 GPU 发送
到目前为止，大多数关注点都集中在管线的“接收和处理”部分。然而，DOCA GPUNetIO 还可以在 GPU 上生成一些数据，制作数据包并从 CUDA 内核发送，而无需 CPU 干预。图 8 描述了一个完整的接收、处理和发送管线的示例。
图 8 . 具有 GPU CUDA 内核的 GPU 数据包处理管线在 GPU 内存中接收数据包，进行数据包处理，最后制作新数据包
NVIDIA DOCA GPUNetIO 示例应用程序
与任何其他 NVIDIA DOCA 库一样，DOCA GPUNetIO 有一个专用应用程序，用于 API 使用参考和测试系统配置和性能。该应用程序实现了前面描述的管线，提供了不同类型的数据包处理，如 IP 校验和、HTTP 数据包过滤和流量转发。
以下部分概述了应用程序的不同操作模式。报告了一些性能数据，将其视为可能在未来版本中更改和改进的初步结果。使用两个基准系统，一个用于接收数据包，另一个用于发送数据包，背靠背连接（图 9）。
运行 DOCA GPUNetIO 应用程序的接收器是带有 NVIDIA BlueField-2X DPU 融合卡的 Dell PowerEdge R750 。该配置为嵌入式 CPU 模式，因此应用程序使用 DPU 上的 NVIDIA ConnectX-6 Dx 网卡和 GPU A100X 在主机系统 CPU 上运行。软件配置为 Ubuntu 20.04 、MOFED 5.8 和 CUDA 11.8 。
发送器是 Gigabyte Intel Xeon Gold 6240R ，其通过 PCIe Gen 3 与 NVIDIA ConnectX-6 Dx 连接。此计算机不需要任何 GPU ，因为它运行 T-Rex DPDK packet generator v2.99 。软件配置为 Ubuntu 20.04 和 MOFED 5.8 。
图 9 . 接收器（Dell R750）和发送器（Gigabyte）系统背靠背连接到基准 NVIDIA DOCA GPUNetIO 应用程序
该应用程序也已在 DPU Arm 内核上执行，导致了相同的性能结果，并证明了以 GPU 为中心的解决方案与 CPU 无关。
请注意，DOCA GPUNetIO 最低要求是具有 GPU 和具有直接 PCIe 连接的 NIC 的系统。DPU 并不是严格要求。
IP 校验和， GPU 仅接收
应用程序使用 GPU 发起的通信来创建一个或多个接收队列以接收分数据包。可以使用单 CUDA 内核或多 CUDA 内核模式。
图 10 . NVIDIA DOCA GPUNetIO 应用程序中的第一个管线模式：GPU 接收、计算 IP 校验和并向 CPU 报告
每个数据包都通过简单的 IP 校验和验证进行处理，只有通过此测试的数据包才算作“好数据包”。通过信号量，好数据包的数量被报告给 CPU ，CPU 可以在控制台上打印报告。
通过使用 T-Rex 数据包生成器以约 100 Gbps（约 11.97 Mpps）的速度发送 30 亿个 1 KB 大小的数据包，并在 DOCA GPUNetIO 应用程序侧报告相同数量的数据包以及正确的 IP 校验和，实现了单队列零数据包丢失。相同的配置在 BlueField-2 融合卡上进行了测试，结果相同，证明了 GPU 发起的通信是一个独立于平台的解决方案。
由于数据包大小为 512 字节，T-Rex 数据包生成器无法发送超过 86 Gbps（约 20.9 Mpps）的数据包。即使每秒数据包的数量几乎是两倍，DOCA GPUNetIO 也没有报告任何数据包丢失。
