深度解析 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 传输。

一、 为什么需要 DMA-BUF？（痛点分析）

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

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

1. ZONE_DEVICE：虽然为设备内存引入了专用page结构，但在 PCI P2P 场景下，它要求由“执行 DMA 的一方”分配缓冲区，这与 GPU 驱动预先分配显存的习惯相悖。

2. HMM（异构内存管理）：支持共享虚拟地址空间，但它倾向于让数据在系统内存和显存间“漂移”（迁移），不支持长期钉住（Pin）内存，且不支持 P2P。

3. DMA-BUF：作为 Linux 内核中跨驱动共享缓冲区的标准机制，它具有天然优势：无需page结构、API 简单灵活、且大多数 GPU 驱动（如 NVIDIA, AMD, Intel）已原生支持。

二、 核心原理：当 RDMA 遇到 ODP

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

1. 解决“钉不住”的问题

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

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

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

2. 关键流程

• 用户态：通过 GPU 驱动获取显存对应的fd（文件描述符）。

• 内核态（RDMA 驱动）：

  1. 调用dma_buf_get(fd)获取对象。

  2. 使用dma_buf_attach()动态挂载。

  3. 通过reg_user_mr_dmabuf注册内存区域（MR）。

三、 补丁系列详解（补丁 ID 概览）

该系列共包含 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：

• 降低 CPU 开销：不再需要在系统内存中中转数据。

• 降低延迟：数据直接通过 PCIe 在 GPU 和 NIC 之间交换。

• 灵活性：不再受限于特定的显存分配器，只要支持 dma-buf 即可。

五、 总结

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

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

参考链接：

• Linux RDMA 补丁详情

• 内核源码相关路径：drivers/infiniband/core/rw.c,drivers/infiniband/hw/mlx5/