On Fri, Sep 26, 2025 at 04:51:29PM +0200, Christian König wrote:
> On 26.09.25 16:41, Jason Gunthorpe wrote:
> > On Fri, Sep 26, 2025 at 03:51:21PM +0200, Thomas Hellström wrote:
> >
> >> Well both exporter and exporter has specific information WRT this. The
> >> ultimate decision is done in the exporter attach() callback, just like
> >> pcie_p2p. And the exporter acknowledges that by setting the
> >> dma_buf_attachment::interconnect_attach field. In analogy with the
> >> dma_buf_attachment::peer2peer member.
> >
> > Having a single option seems too limited to me..
>
> Yeah, agree.
>
> > I think it would be nice if the importer could supply a list of
> > 'interconnects' it can accept, eg:
> >
> > - VRAM offset within this specific VRAM memory
> > - dma_addr_t for this struct device
> > - "IOVA" for this initiator on a private interconnect
> > - PCI bar slice
> > - phys_addr_t (used between vfio, kvm, iommufd)
>
> I would rather say that the exporter should provide the list of what
> interconnects the buffer might be accessible through.
Either direction works, I sketched it like this because I thought
there were more importers than exporters, and in the flow it is easy
for the importer to provide a list on the stack
I didn't sketch further, but I think the exporter and importer should
both be providing a compatible list and then in almost all cases the
core code should do the matching.
If the importer works as I showed, then the exporter version would be
in an op:
int exporter_negotiate_op(struct dma_buf *dmabuf,
struct dma_buf_interconnect_negotiation *importer_support, size_t
importer_len)
{
struct dma_buf_interconnect_negotiation exporter_support[2] = {
[0] = {.interconnect = myself->xe_vram},
[1] = {.interconnect = &dmabuf_generic_dma_addr_t, .interconnect_args
= exporter_dev},
};
return dma_buf_helper_negotiate(dmabuf, exporter_support,
ARRAY_SIZE(exporter_support), importer_support, importer_len);
}
Which the dma_buf_negotiate() calls.
The core code does the matching generically, probably there is a
struct dma_buf_interconnect match() op it uses to help this process.
I don't think importer or exporter should be open coding any matching.
For example, we have some systems with multipath PCI. This could
actually support those properly. The RDMA NIC has two struct devices
it operates with different paths, so it would write out two
&dmabuf_generic_dma_addr_t's - one for each.
The GPU would do the same. The core code can have generic code to
evaluate if P2P is possible and estimate some QOR between the options.
Jason
