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

["Christian König" <christian.koenig@amd.com>]

On 2/9/26 14:06, Jason Gunthorpe wrote:
> On Mon, Feb 09, 2026 at 10:59:53AM +0000, Pavel Begunkov wrote:
> 
>>> As a step forward I could imagine having a DMABUF handing out P2P
>>> pages and allowing io uring to "register" it complete with move
>>
>> Forcing dma-buf to have pages is a big step back, IMHO
> 
> Naw, some drivers already have them anyhow, and we are already looking
> at optional ways to allow a very limited select group of importers to
> access the underlying physical.

That is just between two specific exporters/importers and certainly won't be allowed as common interface.

> It is not a big leap from there to say io_uring pre-registration is a
> special importer that only interworks with drivers providing P2P
> pages.

Completely NAK from my side to that approach.

We have exercised and discussed this in absolutely detail and it is not going to fly anywhere.

The struct page based approach in fundamentally incompatible with driver managed exporters.

Regards,
Christian.

> 
> It could immediately address everything except pre-registration. And
> do you really care about pre-registration? Why? Running performance
> workloads with the iommu doing a DMA mapping is pretty unusual.
> 
>>> Pre-iommu-mapping the pool seems like an orthogonal project as it
>>> applies to everything coming from pre-registered io uring buffers,
>>> even normal cpu memory. You could have a next step of pre-mapping the
>>> P2P pages and CPU pages equally.
>>
>> It was already tried for normal user memory (not by me), but
>> the verdict was that it should be dma-buf based.
> 
> I'm not sure how DMA-buf helps anything here. It is the io uring layer
> that should be interacting with DMA-buf, the lower level stuff
> shouldn't touch it.
> 
> Jason