Re: dma_map_resource() has a bad performance in pcie peer to peer transactions when iommu enabled in Linux

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

Am 02.10.23 um 22:08 schrieb Robin Murphy:
> On 2023-09-26 16:30, Kelly Devilliv wrote:
>> [SNIP]
>> Hi Robin,
>>
>> Is there any chance to extend the dma_map_resource() API as discussed 
>> above?
>
> As Christoph says, no. There are things one could do to make a 
> minimal-effort bodge in a downstream kernel, but upstream we already 
> have a dedicated PCI peer-to-peer API, so we have no reason and no 
> desire to also attempt to crowbar P2P support into a different API 
> which isn't designed for it. Sure there exist some drivers that went 
> ahead of the game and did their own thing before we realised that 
> dma_map_resource() just fundamentally wouldn't be a good fit for P2P 
> as initially suggested, but all that means is that if they're still 
> doing that today, they're now lagging behind and it's on them to 
> update to the newer solution if they want to benefit from all its 
> goodness. Note that this isn't just maintainer semantics or relatively 
> straightforward things like memory attributes; I believe the proper 
> API can also handle stuff like direct P2P when you do have an IOMMU 
> but don't have ACS upstream redirect, which dma_map_resource() could 
> never do.

The problem is that the new API requires to have struct pages for PCIe 
resources which the graphics drivers absolutely don't want to do.

Allocating struct pages for memory mapped I/O simply doesn't make to 
much sense when the underlying resource is not even memory.

Regards,
Christian.

>
> Thanks,
> Robin.