深度解析 RDMA 技术的里程碑：基于 DMA-BUF 的 P2P 直接访问（GPU Direct RDMA 新姿势）

前言

在高性能计算（HPC）和 AI 训练场景中，GPU 与网卡（NIC）之间的数据传输效率至关重要。传统的 RDMA 访问用户空间缓冲区通常依赖 get_user_pages() 来钉住（Pin）物理内存。但当数据驻留在 GPU 显存（VRAM）时，这种方式因缺乏标准 page 结构而失效。

2020 年，Intel 的 Jianxin Xiong 向 Linux 内核提交了一系列补丁（已合入主线），正式引入了 RDMA DMA-BUF 支持。这一特性彻底打通了 RDMA 驱动作为 importer 导入 GPU 显存的路径，实现了更优雅的 P2P 传输。

在传统的 RDMA 操作中，内核需要通过 page 结构来管理内存，但设备内存（如 GPU VRAM）在 Linux 内存管理子系统（MM）中是个"异类"。

目前虽然有几种解决方案，但各有利弊：

ZONE_DEVICE ：虽然为设备内存引入了专用 page 结构，但在 PCI P2P 场景下，它要求由"执行 DMA 的一方"分配缓冲区，这与 GPU 驱动预先分配显存的习惯相悖。
HMM（异构内存管理）：支持共享虚拟地址空间，但它倾向于让数据在系统内存和显存间"漂移"（迁移），不支持长期钉住（Pin）内存，且不支持 P2P。
DMA-BUF ：作为 Linux 内核中跨驱动共享缓冲区的标准机制，它具有天然优势：无需 page 结构、API 简单灵活、且大多数 GPU 驱动（如 NVIDIA, AMD, Intel）已原生支持。

这次合入的主线代码（Patch 1-4）核心逻辑是：让 RDMA 驱动扮演 DMA-BUF 的导入者（Importer）。

有一个棘手的问题：现有的 GPU 驱动通常不允许通过 DMA-BUF 接口"钉住"显存。如果你强行 Pin，显存可能会被置换回系统内存。

解决方案：借力 ODP（On-Demand Paging）。

这组补丁并不强制要求 Pin 内存，而是利用支持 ODP 的网卡。当网卡访问显存时，如果发生缺页，通过 DMA-BUF 的动态挂载（Dynamic Attach）机制实时获取 DMA 地址。

用户态 ：通过 GPU 驱动获取显存对应的 fd（文件描述符）。
内核态（RDMA 驱动）：
1. 调用 dma_buf_get(fd) 获取对象。
2. 使用 dma_buf_attach() 动态挂载。
3. 通过 reg_user_mr_dmabuf 注册内存区域（MR）。

该系列共包含 4 个核心补丁，分工明确：

Patch 1：通用代码引入

添加了从 fd 导入 dma-buf 并映射页面的通用基础代码，为 RDMA 栈提供了处理 dma-buf 的工具函数。
Patch 2：新增驱动方法

引入了 reg_user_mr_dmabuf() 接口。这是对现有 reg_user_mr 的扩展，专门处理基于 dma-buf 的内存注册。
Patch 3：用户态接口（Uverbs Command）

增加了一个新的 uverbs 命令，允许用户空间应用直接把 GPU 的 dma-buf 句柄传给 RDMA 栈。
Patch 4：落地 mlx5 驱动

在 NVIDIA/Mellanox 的 mlx5 驱动中正式实现上述接口。由于 mlx5 是 ODP 技术的代表，因此成为了首个受益者。

通过这一机制，开发者可以实现真正的 Zero-copy P2P：

DMA-BUF 与 RDMA 的结合是 Linux 内核在处理异构计算架构上的重要一步。它不仅简化了网卡访问 GPU 内存的逻辑，也为未来 CXL 等高速互联技术下的内存共享铺平了道路。

对于从事 RDMA 开发或高性能计算的朋友来说，关注 ODP 和 DMA-BUF 的结合将是提升系统吞吐量的关键技巧。

参考链接：