[LSF/MM/BPF TOPIC] dmabuf backed read/write

[Pavel Begunkov]

On 2/24/26 00:13, T.J. Mercier wrote:
> On Tue, Feb 3, 2026 at 6:29 AM Pavel Begunkov <asml.silence at gmail.com> wrote:
>>
>> Good day everyone,
>>
>> dma-buf is a powerful abstraction for managing buffers and DMA mappings,
>> and there is growing interest in extending it to the read/write path to
>> enable device-to-device transfers without bouncing data through system
>> memory. I was encouraged to submit it to LSF/MM/BPF as that might be
>> useful to mull over details and what capabilities and features people
>> may need.
>>
>> The proposal consists of two parts. The first is a small in-kernel
>> framework that allows a dma-buf to be registered against a given file
>> and returns an object representing a DMA mapping. The actual mapping
>> creation is delegated to the target subsystem (e.g. NVMe). This
>> abstraction centralises request accounting, mapping management, dynamic
>> recreation, etc. The resulting mapping object is passed through the I/O
>> stack via a new iov_iter type.
>>
>> As for the user API, a dma-buf is installed as an io_uring registered
>> buffer for a specific file. Once registered, the buffer can be used by
>> read / write io_uring requests as normal. io_uring will enforce that the
>> buffer is only used with "compatible files", which is for now restricted
>> to the target registration file, but will be expanded in the future.
>> Notably, io_uring is a consumer of the framework rather than a
>> dependency, and the infrastructure can be reused.
>>
>> It took a couple of iterations on the list to get it to the current
>> design, v2 of the series can be looked up at [1], which implements the
>> infrastructure and initial wiring for NVMe. It slightly diverges from
>> the description above, as some of the framework bits are block specific,
>> and I'll be working on refining that and simplifying some of the
>> interfaces for v3. A good chunk of block handling is based on prior work
>> from Keith that was pre DMA mapping buffers [2].
>>
>> Tushar was helping and mention he got good numbers for P2P transfers
>> compared to bouncing it via RAM. Anuj, Kanchan and Nitesh also
>> previously reported encouraging results for system memory backed
>> dma-buf for optimising IOMMU overhead, quoting Anuj:
>>
>> - STRICT: before = 570 KIOPS, after = 5.01 MIOPS
>> - LAZY: before = 1.93 MIOPS, after = 5.01 MIOPS
>> - PASSTHROUGH: before = 5.01 MIOPS, after = 5.01 MIOPS
>>
>> [1] https://lore.kernel.org/io-uring/cover.1763725387.git.asml.silence@gmail.com/
>> [2] https://lore.kernel.org/io-uring/20220805162444.3985535-1-kbusch@fb.com/
>> --
>> Pavel Begunkov
>>
> 
> Hi, I'm interested in this topic. I'm guessing this will be in the FS track?

Forgot to mention, I submitted it to the storage track, thanks

-- 
Pavel Begunkov