Re: [RFC PATCH v2 1/2] dma-buf: Add support for private interconnects

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Sep 29, 2025 at 10:25:06AM +0200, Thomas Hellström wrote:
> > > 2) dma-buf pcie-p2p allows transparent fallback to system memory
> > > dma-
> > > buf. I think that is a good thing to keep even for other
> > > interconnects
> > > (if possible). Like if someone wants to pull the network cable, we
> > > could trigger a move_notify() and on next map() we'd fall back. Any
> > > ideas around this?
> > 
> > We already do that if new importers come along.
> > 
> > E.g. you have a connection which can do PCIe P2P and then suddenly
> > somebody attaches which can only do DMA to system memory. In that
> > situation we use move_notify to move the buffer into system memory
> > and imports re-map it to grasp the new location.
> 
> Sure, Just wandering whether we should document and require that also
> for fast interconnects. 

I thin Thomas is pushing toward a question of what happens to the
interconnect during a move?

If the interconnect is established during attach, can/should move
re-negotiate it?

It seems like yes - if the attachment negotiated using some private
interconnect then move happens and the memory is on CPU and no longer
available to the private interconnect the attachment needs to
renegotiate and change to a new interconnect during the move sequence.

If the importer supports only 1 interconnect, then it shouldn't have
to implement renegotiate.

I think this needs to be called out explicitly in the flow and
documentation.

> So that if we use a new map_attachment()
> function, like was suggested ealier, if that fails, the importer should
> ideally retry with the old one to get an sg-list to system memory?

It would be amazing to avoid this hassle, if the core code could see
the exporter is old and automatically match the sg-list behavior to
generic interconnect options. And vice versa for old importers.

Jason