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

[Leon Romanovsky <leon@kernel.org>]

On Tue, Sep 29, 2026 at 11:34:05AM +0200, Christian König wrote:
> On 9/28/26 13:19, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > Exporters keep the &struct p2pdma_provider backing a buffer in their own
> > private data. An importer cannot reach it, so it has no way to learn how
> > its own peer-to-peer traffic would be routed before it programs its
> > hardware.
> > 
> > Add an optional @p2pdma_provider callback for an exporter to hand that
> > provider out, and dma_buf_p2pdma_map_type() for an importer to ask by TLP
> > class. Exporters keep the provider where it already lives, so this adds an
> > operation rather than changing any existing signature or structure.
> > 
> > Tested-by: Tushar Dave <tdave@nvidia.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> >  drivers/dma-buf/dma-buf-mapping.c | 39 +++++++++++++++++++++++++++++++++++++++
> >  include/linux/dma-buf-mapping.h   |  3 +++
> >  include/linux/dma-buf.h           | 19 +++++++++++++++++++
> >  3 files changed, 61 insertions(+)

<...>

> > +enum pci_p2pdma_map_type
> > +dma_buf_p2pdma_map_type(struct dma_buf_attachment *attach,
> > +			unsigned int tlp_flags)
> > +{
> > +	struct dma_buf *dmabuf = attach->dmabuf;
> > +	struct p2pdma_provider *provider;
> > +
> > +	dma_resv_assert_held(dmabuf->resv);
> > +
> > +	if (!dmabuf->ops->p2pdma_provider)
> > +		return PCI_P2PDMA_MAP_NONE;
> > +
> > +	provider = dmabuf->ops->p2pdma_provider(dmabuf);
> > +	if (!provider)
> > +		return PCI_P2PDMA_MAP_NONE;
> > +
> 
> 
> > +	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?

Thanks

> 
> Regards,
> Christian.