On Thu, Dec 10, 2015 at 11:02:02PM -0700, Jason Gunthorpe wrote: > > FYI, I have a patch series in linux-next to switches all remaining > > architectures to use get_dma_ops, and there are plans to allow generic > > per-device dma_ops based on that. > > Great, so once that is merged we can drop the ib_* versions of all > this and just have qib/etc customize get_dma_ops? Other than the > dma_addr_t size issue that sounds great..
I'm not sure the per-device ops are a done deal, as there has been vocal opposition to it everytime it came up. But at least we have the infrastructure for it now. Other than that I think we're getting ready to actually remove dma mapping from the ULPs. Sagi's MR API that takes a scatterlist is a first step, as it would allow for trivially moving the dma_map_sg into the core helpes. For the client side we now just need to switch FMRs to use that API as well (given that it seems like we can't get rid of them) and provide an API to "map" a scatterlist using the DMA MR for those drivers playing fast and loose. On the server side I have a first draft of a R/W API that does RDMA READ/WRITE requests and handles the required registration and invalidation internally. It again takes a scatterlist and handles dma mapping internal. Now all the dma mapping will be in the core, which means they are only one step away from the driver. Now if the per-device dma_ops don't work out we can simply have a flag in struct ib_device that it doesn't need dma mapping and can avoid the indirection through another set of ops at least. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
