On Thu, Jan 31, 2019 at 12:19:31PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-31 12:02 p.m., Jason Gunthorpe wrote: > > I still think the right direction is to build on what Logan has done - > > realize that he created a DMA-only SGL - make that a formal type of > > the kernel and provide the right set of APIs to work with this type, > > without being forced to expose struct page. > > > Basically invert the API flow - the DMA map would be done close to > > GUP, not buried in the driver. This absolutely doesn't work for every > > flow we have, but it does enable the ones that people seem to care > > about when talking about P2P. > > It also does present a path to solve some cases of the O_DIRECT > > problems if the block stack can develop some way to know if an IO will > > go down a DMA-only IO path or not... This seems less challenging that > > auditing every SGL user for iomem safety?? > > > The DMA-only SGL will work for some use cases, but I think it's going to > be a challenge for others. We care most about NVMe and, therefore, the > block layer. The exercise here is not to enable O_DIRECT for P2P, it is to allow certain much simpler users to use P2P. We should not be saying that someone has to solve these complicated problems in the entire block stack just to make RDMA work. :( If the block stack can use a 'dma sgl' or not, I don't know. However, it does look like it fits these RDMA, GPU and VFIO cases fairly well, and looks better than the hacky sgl-but-really-special-p2p hack we have in RDMA today. Jason
