Re: [RFC v2 1/8] dma-buf: Add support for map/unmap APIs for interconnects

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Oct 28, 2025 at 05:39:39AM +0000, Kasireddy, Vivek wrote:
> Hi Jason,
> 
> > Subject: Re: [RFC v2 1/8] dma-buf: Add support for map/unmap APIs for
> > interconnects
> > 
> > On Sun, Oct 26, 2025 at 09:44:13PM -0700, Vivek Kasireddy wrote:
> > > For the map operation, the dma-buf core will create an xarray but
> > > the exporter needs to populate it with the interconnect specific
> > > addresses. And, similarly for unmap, the exporter is expected to
> > > cleanup the individual entries of the xarray.
> > 
> > I don't think we should limit this to xarrays, nor do I think it is a
> > great datastructure for what is usually needed here..
> One of the goals (as suggested by Christian) is to have a container that
> can be used with an iterator.

I thought Christian was suggesting to avoid the container and have
some kind of iterator?

> So, instead of creating a new data structure,
> I figured using an xarray would make sense here. And, since the entries
> of an xarray can be of any type, I think another advantage is that the
> dma-buf core only needs to be aware of the xarray but the exporter can
> use an interconnect specific type to populate the entries that the importer
> would be aware of.

It is excessively memory wasteful.

> > I just posted the patches showing what iommufd needs, and it wants
> > something like
> > 
> > struct mapping {
> >    struct p2p_provider *provider;
> >    size_t nelms;
> >    struct phys_vec *phys;
> > };
> > 
> > Which is not something that make sense as an xarray.
> If we do not want to use an xarray, I guess we can try to generalize the
> struct that holds the addresses and any additional info (such as provider).
> Would any of the following look OK to you:

I think just don't try to have a general struct, it is not required
once we have interconnects. Each interconnect can define what makes
sense for it.

> struct dma_buf_ranges {
>         struct range *ranges;
>         unsigned int nranges;
>         void *ranges_data;
> };

Like this is just pointless, it destroys type safety for no benifit.

> > struct dma_buf_iov_interconnect_ops {
> >      struct dma_buf_interconnect_ops ic_ops;
> >      struct xx *(*map)(struct dma_buf_attachment *attach,
> Do we want each specific interconnect to have its own return type for map?

I think yes, then you have type safety and so on. The types should all
be different. We need to get away from using dma_addr_t or phys_addr_t
for something that is not in those address spaces.

Jason