前言在高性能计算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中是个“异类”。目前虽然有几种解决方案但各有利弊ZONE_DEVICE虽然为设备内存引入了专用page结构但在 PCI P2P 场景下它要求由“执行 DMA 的一方”分配缓冲区这与 GPU 驱动预先分配显存的习惯相悖。HMM异构内存管理支持共享虚拟地址空间但它倾向于让数据在系统内存和显存间“漂移”迁移不支持长期钉住Pin内存且不支持 P2P。DMA-BUF作为 Linux 内核中跨驱动共享缓冲区的标准机制它具有天然优势无需page结构、API 简单灵活、且大多数 GPU 驱动如 NVIDIA, AMD, Intel已原生支持。二、 核心原理当 RDMA 遇到 ODP这次合入的主线代码Patch 1-4核心逻辑是让 RDMA 驱动扮演 DMA-BUF 的导入者Importer。1. 解决“钉不住”的问题有一个棘手的问题现有的 GPU 驱动通常不允许通过 DMA-BUF 接口“钉住”显存。如果你强行 Pin显存可能会被置换回系统内存。解决方案借力 ODPOn-Demand Paging。这组补丁并不强制要求 Pin 内存而是利用支持ODP的网卡。当网卡访问显存时如果发生缺页通过 DMA-BUF 的动态挂载Dynamic Attach机制实时获取 DMA 地址。2. 关键流程用户态通过 GPU 驱动获取显存对应的fd文件描述符。内核态RDMA 驱动调用dma_buf_get(fd)获取对象。使用dma_buf_attach()动态挂载。通过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/