On Thu, Jan 03, 2019 at 02:13:23PM -0500, Doug Ledford wrote: > On Wed, 2019-01-02 at 10:56 -0700, Jason Gunthorpe wrote: > > On Tue, Dec 25, 2018 at 01:17:28AM -0800, Sagi Grimberg wrote: > > > Hi, just happened to see this thread, > > > > > > > I think the unambiguous low bar is enough implemented to run > > > > NVMEoF. That is definitely 'RDMA common verbs' hardware, IMHO. > > > > > > Does this still hold Jason? Would be impossible to meet without > > > implementing RC though... > > > > A driver needs RC + RDMA to be useful to our kernel ULPs. > > > > So the question really is should a driver be merged that can't work > > with any existing ULP? > > All of our ULPs present in drivers/infiniband (but not all of them in > the kernel) have been programmed to the RC model. That's a matter of > implementation, not of requirement. They could have been programmed to > UD if the people wanted. I would argue that to say that today a driver > needs to implement something that was never planned as a functional > requirement but is merely a consequence of chance is arbitrary. > > Secondly, RDMA was *always* about user space memcopy savings, and only > secondarily about kernel protocol support. I gave a talk all the way > back in 2006 at Red Hat Summit about the benefits of RDMA, and the > benefits to the kernel were always minimal compared to the benefits to > user space. Having user space command queues and completion queues and > pre-registered/posted memory buffers completely avoids the memcpy from > kernel to user space associated with all other network technologies. > The kernel didn't get that advantage because the core networking code > can hand a regular tcp skbuff to the nfs code (for instance) without a > memcpy. For that reason, kernel benefits are secondary to user space > benefits when it comes to RDMA. And yet you are arguing that the > kernel's ability to benefit from the driver/hardware should be the > gating factor as to whether or not it should be merged. I have to > disagree. I assume that NVMe over fabric users/developers will disagree with you about such primary/secondary separation. Thanks > > > > Also, note that nvmeof and the others have pretty much the same > > > requirements from the rdma core. > > > > Yes, which is why I pointed at it.. > > > > Jason > > -- > Doug Ledford <dledford@xxxxxxxxxx> > GPG KeyID: B826A3330E572FDD > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: PGP signature
