> > 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. > Other than that, this seems broadly reasonable to me as a way to access a DMA buf pointing at system memory, though it would be nice to > have a rational for why we should do this rather than rely on mmap'd versions of a dma buf. > > Jason
