On 2026-10-22 at 17:59 +1100, Thomas Hellström <[email protected]> wrote... > On Wed, 2026-10-21 at 09:37 -0300, Jason Gunthorpe wrote: > > On Wed, Oct 21, 2026 at 08:24:40AM +0200, Thomas Hellström wrote: > > > > struct dma_buf_mapping_exp_ops > > > > Base type for the per-mapping type exporter provided > > > > functions. > > > > This > > > > would be the map/unmap callbacks. Each mapping type can > > > > provide > > > > its own > > > > functions for map/unmap type operations with optimal type > > > > signatures. > > > > > > Does it make sense to try to land this patch first, plus a > > > conversion > > > of pcie_p2p so we could agree on what the contract should look > > > like? > > > > I think it would be good to focus on this patch as the main 'crux' of > > the series. The API contract is the main agreement. I'm relucant to > > merge code that has no users, so it woudl be ebtter to go up to at > > least through SGT. > > I agree about unused code, but wouldn't a pcie_p2p conversion to a > mapping type be a valid use-case?
In some ways I think having both sgt and the pcie_p2p conversion is helpful as it demonstrates how different mapping types are used. I agree the important bit is settling on the contract though. Adding a pcie_p2p conversion on top doesn't look too hard though. Thomas would you be ok if I rebased and posted some of your patches[1] adding pcie_p2p on top of the mapping types + SGT conversion v2 I'm getting ready to send to demonstrate usage? Or would you rather do that after I send? [1] - https://gitlab.freedesktop.org/thomash/xe-vibe/-/commit/7452df0fc858a7dc5ccac0e2037852cb7ab64d61 - Alistair > > > > > s/mapping/interconnect/? My gut feeling is that "interconnect" best > > > describes what's typically going on, but "mapping" perhaps better > > > describes all cases. > > > > My intention was to cover more than just the phyiscal transport. We > > do > > really want to get away from scatterlist, so having PCIe map with > > scatterlist and PCIe map with <something else> still ends up with two > > mapping types in the system. > > > > This is why I choose the name over interconnect. > > > > > Location of common protocols which typically carry cross-subsystem > > > dependencies? > > > drivers/dma-buf/mapping_types? drivers/dma-buf/interconnects? > > > > I'd encourage people to design more like PCI where the actual > > *interconnect* has its own home and there is just some minor call > > outs > > from dmabuf to help the matching logic. > > > > > As discussed previously: > > > Agree on theoretically possible matches at attach time, Match at > > > mapping time and guarantee the match is valid until > > > invalidate_mappings(). > > > > I was thinking about this some more, and I'm less sure now. > > > > If I think about mlx5, in a multi-path PCIe configuration, it can > > move > > the translation around within a single PCIe path, but it cannot move > > it to another path without creating disruption for the > > application. This is a HW limitation in how the internal routing > > works.. > > > > I strongly suspect this will be the norm for any hardware that > > doesn't > > rely on decorated page tables to select the IO path.. > > > > So, while I agree we should support hardware that can fully change > > the > > path on each and every map, we also need to suport hardware that must > > pin the path during attach. > > > > Probably this points to needing a 'pin' operation for the mapping > > selection after attach. > > > > > > +/* > > > > + * Match items are generated by the importer using the > > > > DMA_BUF_IMAPPING_*() and > > > > + * the exporter using the DMA_BUF_EMAPPING_*() functions. Each > > > > mapping type > > > > + * defines its own signature with its own data to make the match > > > > and > > > > attachment. > > > > + */ > > > > +struct dma_buf_mapping_match { > > > > + const struct dma_buf_mapping_type *type; > > > > + const struct dma_buf_mapping_exp_ops *exp_ops; > > > > + union { > > > > + /* Each mapping_type has unique match parameters > > > > here */ > > > > + }; > > > > > > Do we really need to add all global mapping types here? Then we'd > > > need > > > something for driver-private mapping types as well. > > > > IIRC it is fixed size up front like this because of how the > > structure's memory is managed in this design.. > > > > If you want a driver private thing then I'd add a 'u64 > > driver_private[2]' to the union and the driver can cast over it. > > > > But this is the kernel, if you want to add an xe_mapping_type, then > > just add it. I don't know we need to do driver private things. > > I guess it's my wish to separate components. Couldn't this lead to > excessive includes and unnecessary dma-buf recompilations when mostly > unrelated headers are touched? Except possibly for memory size, core > dma-buf shouldn't need to know about this, it's a mapping private > thing? > > /Thomas > > > > > > Jason
