On Thu, Apr 16, 2020 at 07:08:15PM +0000, Xiong, Jianxin wrote: > > > This patch set adds dma-buf importer role to the RDMA driver and thus > > > provides a non-proprietary approach for supporting RDMA to/from > > > buffers allocated from device local memory (e.g. GPU VRAM). > > > > How exactly does this allow access to GPU VRAM? > > > > dma_buf_attach() cannot return non-struct page memory in the sgt, > > and I'm not sure the API has enough information to do use the > > p2pdma stuff to even establish a p2p mapping. > > > > We've already been over this in another thread.. There is a way to > > improve things to get there, but I don't understand how this patch > > series is claming to be able to work with VRAM - if it is that > > means there is a bug in a GPU driver that should be squashed. > > > > Right, the GPU driver needs to cooperate to get the thing to work as > expected. The "p2p" flag and related GPU driver changes proposed in > other threads would ensure VRAM is really used. Alternatively, a > GPU driver can have a working mode that assumes p2p mapping > capability of the client. Either way, the patches to the RDMA driver > would be mostly identical except for adding the use of the "p2p" > flag. I think the other thread has explained this would not be "mostly identical" but here is significant work to rip out the scatter list from the umem. So, I'm back to my original ask, can you justify adding this if it cannot do VRAM? What is the use case? Jason
