On Tue, Jul 09, 2024 at 03:53:15PM -0300, Jason Gunthorpe wrote: > > That whole thing of course opens the question if we want a pure > > in-memory version of the dma_addr_t/len tuple. IMHO that is the best > > way to migrate and allows to share code easily. We can look into ways > > to avoiding that more for drivers that care, but most drivers are > > probably best serve with it to keep the code simple and make the > > conversion easier. > > My feeling has been that this RFC is the low level interface and we > can bring our own data structure on top. > > It would probably make sense to build a scatterlist v2 on top of this > that has an in-memory dma_addr_t/len list close to today Yes, the usage of the dma_vec would be in a higher layer. But I'd really like to see it from the beginning. > . Yes it costs > a memory allocation, or a larger initial allocation, but many places > may not really care. Block drivers have always allocated a SGL, for > instance. Except for those optimizing for snall transfer of a single segment (like nvme). > My main take away was that we should make the dma_ops interface > simpler and more general so we can have this choice instead of welding > a single datastructure through everything. Yes, I don't think the dma_vec should be the low-level interface. I think a low-level interface based on physical address is the right one. I'll see what I can do to move the single segment map interface to be physical address based instead of page based so that we can unify them.
