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
