> > > > > > > > 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. > > > > > > > Probably we are referring to different threads here. Could you kindly > > refer me to the thread you mentioned? I was referring to the thread > > about patching dma-buf and GPU driver: > > https://www.spinics.net/lists/amd-gfx/msg47022.html > > https://lore.kernel.org/linux-media/20200311152838.GA24280@xxxxxxxxxxxxx/ > Thanks. We are actually looking at the same series but somehow I skipped the details of the single patch that looks simplest which turns out to have most complication. I agree if scatter list is not to be used, there are going to be significant work involved. > > > So, I'm back to my original ask, can you justify adding this if it > > > cannot do VRAM? What is the use case? > > > > Working with VRAM is the goal. This patch has been tested with a > > modified GPU driver that has dma_buf_ops set up to not migrate the > > buffer to system memory when attached. The GPU drivers and the RDMA > > drivers can be improved independently and it doesn't hurt to have the > > RDMA driver ready before the GPU drivers. > > Well, if there is no other use case then this series will have to wait until someone does all the other work to make P2P work upstream. > > Jason
