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.
> > 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: This is a digitally signed message part
