On 9/30/26 13:43, Leon Romanovsky wrote:
On Wed, Sep 30, 2026 at 10:34:56AM +0200, Christian König wrote:
On 9/30/26 10:18, Leon Romanovsky wrote:
...
At a minimum, exporters need to pass `p2pdma_provider`.
No, exactly that is a no-go. The neither the framework nor the importer should see the p2pdma_provider.
Only fully translated addresses where the DMA access should happen.
If I keep the “dma-buf: Let exporters hand out the P2PDMA provider behind a buffer” patch, I can move the P2P TLP types back into `p2pdma.c` and export only the function that indicates whether ATS is required.
Is it ok?
What you can do is to forward declare enum pci_p2pdma_map_type and than pass that 1 to 1 from the exporter to the importer.
Unfortunately, neither suggestion applies to RDMA NICs. They need to know, before mapping addresses, whether to create the memory region with ATS enabled.
The design principle here is that the final location and access path of the data isn't determined when the buffer is created.
The importer first need to attach before it can query such information from the exporter.
The importer needs a way to obtain device information from the exporter so that it can configure itself correctly.
That won't work with DMA-buf then, the exporter is completely opaque to the importer and that is for really good reasons.
Why in the world does the importer needs to know the information from the exporter before the mapping is created?
It is the exporter who decides how data is accessed by the importer and not the other way around.
Regards, Christian.
Thanks