LWN：设备发起的 I/O

关注了就能看到更多这么棒的文章哦～

Device-initiated I/O

By Jake Edge
June 4, 2025
LSFMM+BPF
Gemini-2.5-flash translation
https://lwn.net/Articles/1022718/

Peer-to-peer DMA (P2PDMA) 自 2018 年 4.20 版本发布以来，一直是 内核 (kernel) 的一部分；它提供了一个框架 (framework)，允许设备 (device) 之间直接传输数据，而无需使用系统内存 (system RAM) 进行传输。在 2025 年 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF) 上，Stephen Bates 主持了一个存储、文件系统 (filesystem) 和内存管理 (memory management) 的联合会议，讨论了设备发起 I/O (device-initiated I/O)，这也许正是 P2PDMA 的发展方向。两年前，他曾在该峰会上主持过 关于 P2PDMA 的会议；今年的会议则是对 P2PDMA 的一个简要更新，并展望了它的未来发展方向。

他首先回顾了 P2PDMA 的现状。它最初是一个内核内 (in-kernel) 的 API(应用程序接口)，用于在PCIe设备之间启用DMA(直接内存访问) 请求；该 API 的首批用户之一是NVMe-over-fabrics的目标端 (target)，它允许数据通过RDMA(远程 DMA) 直接流入NVMe驱动器。后来添加了从user space(用户空间) 访问该功能的能力，以便可以使用mmap()来映射设备内存。一些公司正在使用此功能，有时还会配合扩展功能的out-of-tree patches(不在主线中的补丁)。

Bates 承认由于工作变动和其他分散注意力的事，他有一段时间没有关注 P2PDMA 了，因此在某些方面不太确定该功能的现状。他询问了 Arm 64-bit 的支持情况；Christoph Hellwig 表示已经支持，Bates 说，这意味着 architecture support (架构支持) 相当完善了。

他说，在存在 I/O memory-management unit (IOMMU) (I/O 内存管理单元) 的情况下尝试进行 P2PDMA 曾经很困难，所以最初用户会关闭 IOMMU；现在已经不需要了。一些 PCIe 功能已经获得了支持，包括 page request interface (PRI) (页面请求接口) 和 address translation services (ATS) (地址转换服务)；他说，这些功能旨在改进情况，但最终也让一切变得更复杂。

设备发起

他本次会议的目标是讨论“点对点 (peer-to-peer) 的下一个自然发展方向是什么，那就是设备发起 I/O”。Bates 说，峰会的前两天很有趣；他一直在与其他与会者讨论 PCIe 设备的进展速度，以及新型 NVMe SSD (固态硬盘) 上 IOPS (每秒 I/O 操作数) 的增长情况。block layer (块层) 也能够处理更多的 IOPS，有人报告称，“经过修改的” io_uring 可以达到每个 core (核心) 高达 6000 万 IOPS，尽管 Bates 指出这个确切数字应持保留态度，但总的来说，IOPS 正在增长。

他说，有人报告称，在 IOMMU pass-through mode(IOMMU 直通模式) 下，NVMe driver(NVMe 驱动) 可以支持每个core800 万 IOPS，但 Jens Axboe 表示，他的测试在某个基于Threadripper的系统上显示约为 1000 万至 1200 万 IOPS。Bates 说，这些数字差异很大，取决于其他因素，例如系统温度（也就是取决于CPU是否受到散热限制）。当需要建立DMA mapping(DMA 映射) 并对 IOMMU 进行programming windows(编程窗口) 时，NVMe driver 只能维持约 200 万 IOPS。他指出，LSFMM+BPF 上有一些关于改进 DMA-mapping code的会议，这可能有助于减少部分overhead(开销)。

但处理 800 万 IOPS 会占用整个 CPU core 来进行 I/O，而且即将推出的 SSD 可以达到 1000 万 IOPS。人们购买快速昂贵的处理器，却将所有周期 (cycle) 都花在处理 I/O 上，这似乎很可惜。他说，有两种方法可以改善这种情况：要么减少每次 I/O operation (I/O 操作) 所需的 CPU instruction (CPU 指令) 数量，要么让设备自己发起 I/O。Matthew Wilcox 称之为“NVMe 队列提交指令”的 Intel CPU 指令可能有所帮助，尽管 Hellwig 指出，“指令数量”不一定等于花费的时间，因为指令占用的周期数是可变的。

Bates 说，既然已经可以像从 PCIe设备进行DMA那样做，那么“具有足够智能、能够在设备上运行代码来生成NVMe-submission-queue(NVMe 提交队列) 条目并敲响门铃 (doorbells)”的accelerator(加速器) 或其他某种I/O device(I/O 设备) 就可以处理自己的 I/O——或者其他设备的 I/O。这个智能设备会运行足够多的NVMe driver来执行I/O requests(I/O 请求)。他提到一篇论文，报告了 NVIDIA 和伊利诺伊大学使用GPU(图形处理器) 进行 NVMe I/O 的工作，尽管那只是一个概念验证 (proof of concept)。Hellwig 指出，Mellanox（现已成为 NVIDIA 的一部分）在那篇论文发表之前很久就已经为RDMA做了类似的事情。Bates 说，曾有过为此目的的patch(补丁)，但他认为它们没有被合并 (merged)；Jason Gunthorpe 则说该功能目前已是shipping product(已出货产品) 的一部分。

Bates 希望看到一个开放、vendor-neutral (厂商中立) 的设备发起 I/O 的 framework，“让任何想参与的人都能在这个领域发挥作用”。他认为这需要包含一种请求和保留 NVMe hardware queues 的方式，尽管 Hellwig 认为这不可行。Bates 说，出于错误处理 (error-handling) 的原因，以及可能需要将其与文件系统 (filesystem) 关联起来，他不想将设备的控制权完全从 kernel 转移出去（就像 SR-IOV 或 VFIO 那样）。他认为管理方面 (administrative side) 也将保留在 kernel 中。

如果这个功能被添加，显然需要某种 protection (保护)，以防止设备随意读写 (read and write)。曾有人讨论过 NVMe 的“protection domains”(保护域)，但他认为它们没有被添加到规范 (specification) 中。让 NVMe 具备限制特定 queue (队列) 允许执行的 operation (操作) 类型的功能将非常有用。例如，它们可以被限制使用特定的 namespace (命名空间) 或该命名空间的 LBA (逻辑块地址) 范围。这样，如果设备“有点失控”，controller (控制器) 就会“像守卫一样行动”。

Hellwig 说，要做这些事情，需要一个独立的 NVMe controller，可以用来关闭行为异常的设备。这是一个昂贵的选项，这就是为什么人们正在寻找其他解决方案。然而，Bates 说他“不完全相信”这是唯一的出路。

一个“捣乱的设备”可能做的另一件事是为 DMA operation (DMA 操作) 提供一个无效的目标地址，无论是恶意的还是意外的。Gunthorpe 说，IOMMU 已经能够处理这类问题，并且使用它们的代码在 kernel 中是可用的。

Hellwig 详细介绍了一些为 Parallel NFS(pNFS) (并行 NFS) 所做的工作，这些工作可能适用于这个use case(用例)。这需要使用layout leases(布局租约)，它保留了文件在storage medium(存储介质) 上的block layout(块布局)，但当布局改变时，kernel可以随时撤销 (revocable) 该lease。他说他和一些同事正在考虑撰写一篇关于将该technique(技术) 用于GPU的论文；他笑着说：“你应该给我们一些好的硬件 (hardware)，这样你就会被提及。”

Bates 说，这听起来是设备发起 I/O 的一个有前景的方向，他还有一个略有不同的主题，想在剩下的几分钟里讨论。有一家大型的 accelerator 公司声称，“AI workload (AI 工作负载) 需要大量的 IOPS”，每个 GPU 大约 2 亿 IOPS，这是巨大的数字。I/O operation 很小，小于 512 字节——比一个块 (block) 的大小还要小——而且 workload (工作负载) 是只读的 (read-only)。“试图通过标准的 NVMe command (NVMe 命令) 来做这件事似乎非常愚蠢。”

NVMe 有一个用于 CMB(控制器内存缓冲区) 的BAR(基地址寄存器)，可以用来允许AI accelerator(AI 加速器) 进行load and store operation(加载和存储操作)，就像对persistent memory(持久内存) 一样。Bates 说，CXL也有类似的功能。该NVMe buffer(NVMe 缓冲区) 可以被映射 (mapped) 到特定的namespace或 namespace 中的一个范围，并允许加速器对数据进行类似 CXL 的memory access(内存访问)。Hellwig 说，使用 CMB 不是正确的方法，因为它会很慢，命令开销 (command overhead) 太大；相反，应该使用 BAR 从只读 (read-only) 的 namespace 创建一个direct mapping(直接映射)。他十年前就用过一个可以做到这一点的NVMe device，所以很容易做出一个概念验证 (proof of concept)，但要将其添加到 NVMe 规范中需要更长时间。

此时，由于时间到了，对话分成了几个小组。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～