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