Re: [PATCH v8 16/23] dma-buf: Let importers ask how peer-to-peer traffic is routed

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

On 9/29/26 19:57, Leon Romanovsky wrote:
> On Tue, Sep 29, 2026 at 03:39:42PM +0200, Christian König wrote:
>> On 9/29/26 15:23, Leon Romanovsky wrote:
>>> On Tue, Sep 29, 2026 at 11:34:05AM +0200, Christian König wrote:
>>>> On 9/28/26 13:19, Leon Romanovsky wrote:
>> ...>>
>>>>> +	return pci_p2pdma_map_type_tlp(provider, attach->dev, tlp_flags);
>>>>
>>>> This function call here *must* be in the exporter and not the DMA-buf framework.
>>>>
>>>> So clear NAK to putting that here.
>>>
>>> "Look, it is easy to complain you don't like how it looks, but this
>>> stuff is hard there are lots of competing concerns, if you have a
>>> better idea now is a good time to present it."
>>> https://lore.kernel.org/all/20260921130858.GO11599@ziepe.ca/#t
>>>
>>> Do you have a viable solution?
>>
>> Ok, that sounds like you haven't understood why I'm rejecting this.
>>
>> By moving the calls to pci_p2pdma functions into DMA-buf you bypass the NAK to expose those functions to drivers from the DMA maintainers.
> 
> No, you have misunderstood Hellwig's position. His request was to ensure that only
> subsystems deal with P2P internals. He was perfectly fine with bringing P2P
> complexity into dma-buf, since it is the agreed-upon mechanism for sharing DMA
> regions between devices.

Thanks for clearing that up, I indeed didn't realized that.

But that is pretty much against my standpoint that I don't want any P2P complexity in DMA-buf.

> 
> So this is not a NAK bypass; it is a correct implementation of his request.
> He handled P2P-related complexity in the block layer.
> 
> Let's add Christoph to the thread so he can correct me if I'm wrong.
> 
>>
>> I unfortunately didn't understood that when the dma-buf-mapping.c code was added and just assumed that you just needed a place to put some common code.
> 
> That is not correct. Devices A and B share a DMA region via the dma-buf
> mechanism. Where do you expect the code common to dma-buf to be placed?

In the DMA layer!

>>
>> So as long as that NAK from the DMA maintainers to expose the pci_p2p functions to drivers stand I will push hard to get that stuff removed again from DMA-buf as well.
> 
> Are you seriously suggesting that every dma-buf driver in the world should
> have to reimplement this mess?

Well I completely agree that this should probably not be replicated into each exporter, but that is the job of the DMA layer and not DMA-buf.

The purpose of DMA-buf is to exchange DMA addresses between an exporter and one or more importers and handle things like lifetime and synchronization of accesses. 

What the framework should do is to transport the capabilities of the importer to the exporter, e.g. what physical connections we have etc..

What the framework can also do is to have additional information from the exporter to the importer regarding addresses and mappings, for example if they are bus, IOVA or some special internal DMA addresses or how to stitch together your PCIe TLP or whatever.

As long as both the exporter and importer agree on what those values mean I have no problem at all with that.

But how those DMA addresses come to be should *absolutely not* be part of DMA-buf! The complexity of that is seriously not something we should have here.

Regards,
Christian.

> 
> Thanks
> 
>>
>> What you try to do here is seriously not ok and I will push back hard on that in the future.
>>
>> Regards,
>> Christian.
>>
>>>
>>> Thanks
>>>
>>>>
>>>> Regards,
>>>> Christian.
>>
>>