On Mon, Jan 21, 2019 at 12:23:37AM -0800, Christoph Hellwig wrote: > On Sun, Jan 20, 2019 at 10:15:52AM +0200, Gal Pressman wrote: > > > I'm not sure what it is even doing with this memory, mmaping system > > > pages from kernel to user is kind of backwards from the usual RDMA > > > driver flow.. > > > > We currently require both RQ and CQ to be physically contiguous. > > We will move the allocation to the userspace provider once we support virtually > > Yikes. Mapping kernel allocations to userspace is in many ways to much > saner than locking down random user memory. See the other thread that > I need to get back to. RDMA relies on being able to DMA to arbitary user pages, so it usually doesn't make much sense to have a different DMA flow for the various control rings vs the user data. It just creates code duplication in the kernel. If a driver maps kernel pages then it has to be responsible for doing it right, like checking RLIMIT_MEMLOCK, and ensuring the pages and the mapping work properly during disassociate rmmod, which is not terribly straightforward for them right now.. So drivers will generally be less buggy if they use the umem flow instead. But if there was a reason to prefer mmaping from kernel we'd have to build some umem-like infrastructure to manage it properly. Jason
