解决方案

SOLUTION DETAIL

使用 NVIDIA DOCA GPUNetIO 解锁 GPU 加速的 RDMA

使用 NVIDIA DOCA GPUNetIO 解锁 GPU 加速的 RDMA:NVIDIA DOCA GPUNetIO是 NVIDIA DOCA SDK 中的一个库,专门为实时内联 GPU 数据包处理而设计

当前位置:首页 > 解决方案
使用 NVIDIA DOCA GPUNetIO 解锁 GPU 加速的 RDMA
解决方案
SOLUTION OVERVIEW

使用 NVIDIA DOCA GPUNetIO 解锁 GPU 加速的 RDMA

使用 NVIDIA DOCA GPUNetIO 解锁 GPU 加速的 RDMA:NVIDIA DOCA GPUNetIO是 NVIDIA DOCA SDK 中的一个库,专门为实时内联 GPU 数据包处理而设计

  • 方案分类 解决方案
  • 内容形式 场景方案 / 技术解析
  • 服务支持 咨询、测试申请、实施建议

如果你正在评估对应场景,我们可以基于当前方案继续细化产品组合、测试路径与实施节奏。

浏览更多相关方案
DETAIL MODULES

方案详情

查看方案背景、关键能力与适配场景,帮助你更快判断下一步应进入测试、咨询还是部署阶段。

image.png

NVIDIA DOCA GPUNetIO是 NVIDIA DOCA SDK 中的一个库,专门为实时内联 GPU 数据包处理而设计。它结合了GPUDirect RDMA和GPUDirect Async等技术,能够创建以 GPU 为中心的应用程序,其中 CUDA 内核可以直接与网络接口卡(NIC)通信,用于发送和接收数据包,绕过 CPU 并将其排除在关键路径之外。

 DOCA GPUNetIO 的核心原理和用途已在前几篇文章《Inline GPU Packet Processing with NVIDIA DOCA GPUNetIO》和《Realizing the Power of Real-Time Network Processing with NVIDIA DOCA GPUNetIO》以及DOCA GPUNetIO 编程指南中进行了讨论。

 此前,DOCA GPUNetIO与DOCA Ethernet和DOCA Flow一起,仅限于处理以太网传输层上的数据包传输。随着 DOCA 2.7 的推出,现在有一组扩展的 API使 DOCA GPUNetIO 能够直接从 GPU CUDA 内核使用 RoCE 或 InfiniBand 传输层支持 RDMA 通信。

 RDMA 首字母缩写描述了一种协议,该协议允许从一台计算机的存储器到另一台计算机存储器的远程直接存储器访问,而不涉及任何一台计算机中的操作系统。操作示例包括 RDMA 写入和 RDMA 读取。不能将其与GPUDirect RDMA混淆,后者与 RDMA 协议无关。GPUDirect RDMA 是 NVIDIA 在 GPUDirect 技术家族中启用的技术之一,使网卡能够绕过 CPU 内存副本和操作系统例程,直接发送或接收访问 GPU 内存的数据。GPUDirect RDMA 可以由任何使用以太网、InfiniBand 或 RoCE 的网络框架启用。

具有 GPUNetIO 的 RDMA GPU 数据路径

RDMA 提供了在两个主机的主内存之间的直接访问,而不涉及操作系统、缓存或存储。这使得数据传输具有高吞吐量、低延迟和低 CPU 利用率。这是通过注册并共享本地内存区域,以便远程主机知道如何访问它。

 两个对等方需要通过 RDMA 交换数据的应用程序通常遵循三个基本步骤:

 

步骤 1–本地配置:每个对等端在本地创建 RDMA 队列和内存缓冲区,以便与其他对等端共享这些资源。

步骤 2–交换信息: 使用带外(OOB)机制(例如,Linux 套接字),对等端交换有关 RDMA 队列和要远程访问的内存缓冲区的信息。

步骤 3–数据路径:两个对等方使用远程内存地址执行 RDMA 读、写、发送和接收,以交换数据。

DOCA RDMA 库按照上面列出的三个步骤通过 InfiniBand 或 RoCE 实现 RDMA 通信,所有这些步骤都是用 CPU 执行的。随着新GPUNetIO RDMA功能的引入,应用程序可以在 GPU 上执行步骤 3,使用 CUDA 内核管理 RDMA 应用程序的数据路径,而步骤 1 和 2 保持不变,因为它们与 GPU 数据路径无关。

 将 RDMA 数据路径移动到 GPU 上的好处与以太网用例中的好处相同。在数据处理发生在 GPU 上的网络应用程序中,将网络通信从 CPU 卸载到 GPU,使其能够成为应用程序的主控制器,消除与 CPU 交互所需的额外延迟,知道数据何时准备就绪以及数据位于何处,这也释放了 CPU 周期。此外,GPU 可以同时并行管理多个 RDMA 队列,例如,每个 CUDA 块可以在不同的 RDMA 队列上发布 RDMA 操作。

 IB Verbs 和 DOCA GPUNetIO 性能测试

在 DOCA 2.7 中,引入了一个新的 DOCA GPUNetIO RDMA 客户机-服务器代码示例,以显示新 API 的使用情况并评估其正确性。这篇文章分析了 GPUNetIO RDMA 函数与 IB Verbs RDMA 函数之间的性能比较,重现了众所周知的 perftest 套件中的一个微基准。

 简而言之,perftest 是一组微基准点,用于使用基本的 RDMA 操作测量 RDMA 带宽(BW)和两个对等点(服务器和客户端)之间的延迟尽管网络控制部分发生在 CPU 中,但可以通过启用 GPUDirect RDMA 并指定--use_cuda标志来指定数据是否驻留在 GPU 内存中。

image.png

一般来说,RDMA 写单向 BW 基准测试(即 ib_write_bw)在每个 RDMA 队列上发布一个针对相同大小消息的写请求列表,用于固定迭代次数,并命令 NIC 执行发布的写操作,这就是所谓的“按门铃”程序。为了确保所有写入都已发出,在进入下一次迭代之前,它轮询完成队列,等待每个写入都已正确执行的确认。然后,对于每个消息大小,可以检索发布和轮询所花费的总时间,并以 MB/s 为单位计算 BW。

Ib_write_bw性能测试主循环迭代中,CPU 发布一个 RDMA 写入请求列表,命令 NIC 执行这些请求,然后等待完成后移动到下一次迭代。启用 CUDA 标志后,要写入的数据包将从 GPU 内存本地获取,而不是从 CPU 内存。

实验是用 DOCA 库复制ib_write_bw微基准标记,使用 DOCA RDMA 作为 CPU 上的控制路径以建立客户端-服务器连接,并使用 DOCA GPUNetIO RDMA 作为数据路径,在 CUDA 内核内发布写入。这种比较并不完全一致,因为 perftest 使用 GPUDirect RDMA 来传输数据,但网络通信由 CPU 控制,而 DOCA GPUNetIO 同时使用 GPUDirect RDMA 和 GPUDirect Async 来控制网络通信和来自 GPU 的数据传输。目标是证明 DOCA GPUNetIO RDMA 性能与 IB Verbs 性能测试相当,后者被视为基线。


为了重现ib_write_bw数据路径并测量针对每个消息大小发布 RDMA 写入操作所花费的时间,CPU 记录一个 CUDA 事件,启动rdma_write_bw CUDA 内核,然后记录第二个 CUDA 事件。这应该可以很好地近似 CUDA 内核使用 DOCA GPUNetIO 函数发布 RDMA 写入所用的时间(以毫秒为单位)。在每次迭代时,GPU CUDA 内核并行发布一个 RDMA 写入请求列表,每个 CUDA 块中的 CUDA 线程一个。在同步所有 CUDA 线程后,只有线程 0 命令 NIC 执行写入并等待完成,然后刷新队列,最后再进行下一次迭代。

EVALUATION CHECKLIST

方案评估清单

在进入报价、测试或实施前,先把业务目标、现网条件和风险边界整理清楚。

GOAL

业务目标

明确要解决的性能、扩容、稳定性、覆盖、互连或运维问题,并确认上线优先级。

NETWORK

现网条件

整理拓扑、服务器/交换机型号、接口速率、链路距离、供电散热和现有管理平台。

VALIDATION

验证范围

确认是否需要 PoC、兼容测试、吞吐测试、时延测试、无线覆盖测试或故障切换测试。

DELIVERY

落地边界

确认交付窗口、责任分工、备件策略、培训需求、验收指标和后续扩容路径。

ANSWER FIRST

方案快速回答与常见问题

先回答“适合谁、如何评估、下一步怎么做”,再决定是否继续进入测试与实施阶段。

FIT CHECK

先判断当前方案是否匹配业务目标和现网条件

如果你已经明确业务规模、性能目标和实施时间,这类方案更容易直接转化为可执行的落地路径。

TEST PATH

不确定时,优先进入咨询与测试验证

对兼容性、吞吐、延迟和交付风险有要求的项目,更适合先通过 PoC 或测试申请把关键问题前置。

NEXT STEP

整理现网信息后,再细化产品组合与实施建议

业务规模、接口需求、现网架构和时间节点越清楚,后续选型、测试和部署节奏越容易收敛。

FAQ 01

使用 NVIDIA DOCA GPUNetIO 解锁 GPU 加速的 RDMA 适合什么业务场景?

适合已经明确业务目标,需要继续判断网络架构、产品组合和实施路线的团队,用于加快技术评估与落地决策。

FAQ 02

评估方案前需要准备哪些信息?

建议准备业务规模、性能目标、现网架构、关键接口、时间节点,以及是否需要测试验证等信息。

FAQ 03

是否可以先做测试或 PoC?

可以。对于需要验证兼容性、性能或交付风险的项目,可先进入咨询、测试申请和 PoC 节奏,再推进部署。

FAQ 04

如何继续获取实施建议?

可在当前方案基础上继续沟通品牌方向、业务场景、计划规模和时间要求,再细化产品组合、测试路径和实施建议。

FAQ 05

判断方案是否适配时最先看什么?

建议先看业务目标、现网瓶颈、性能指标、扩展规模、上线窗口和预算约束,再判断方案架构与产品组合是否匹配。

FAQ 06

方案落地前有哪些风险需要前置确认?

需要前置确认兼容性、链路带宽、时延要求、设备供电与散热、施工窗口、测试范围和交付责任边界。