On Wed, Aug 19, 2015 at 02:56:24PM +0300, Sagi Grimberg wrote: > So I had a go with moving the DMA mapping into ib_map_mr_sg() and > it turns out mapping somewhat poorly if the ULP _may_ register memory > or just send sg_lists (like storage targets over IB/iWARP). So the ULP > will sometimes use the DMA mapping and sometimes it won't... feels > kinda off to me... Yes, it's odd. > it's much saner to do: > 1. dma_map_sg > 2. register / send-sg-list > 3. unregister (if needed) > 4. dma_unmap_sg > > then: > 1. if register - call ib_map_mr_sg (which calls dma_map_sg) > else do dma_map_sg > 2. if registered - call ib_dma_unmap_sg (which calles dma_unmap_sg) > else do dma_unmap_sg > > this kinda forces ULP to completely separate these code paths with > with very little sharing. > > Also, at the moment, when ULPs are doing either FRWR or FMRs > its a pain to get a non-intrusive conversion. > > I'm thinking we should keep dma_map_sg out of ib_map_mr_sg, and leave > it to the ULP like it does today (at least in the first stage...) Keep it out for now. I think we need to move the dma mapping into the RDMA care rather sooner than later, but that must also include ib_post_send/recv, so it's better done separately. After having a look at the mess some drivers (ipath,qib,hfi & ehca) cause with abuse of dma_map_ops I've got an even strong opion on the whole subject now. However I think we'll get more things done if we split them into smaller steps. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
