On 12/5/2018 11:05 AM, Jason Gunthorpe wrote:
On Wed, Dec 05, 2018 at 10:54:38AM -0500, Dennis Dalessandro wrote:
3) We need to see the userspace for new drivers. A RDMA driver that
doesn't provide a useful rdma-core provider is deeply suspect as
not crossing the #1 threshold.
We'll be publishing our libfabric userspace provider soon, I'll add
a link once it's available.
libfabric does not do the checks on the ABI construction that
rdma-core does, so that still has to be done somehow
Are you wanting to draw a line in the sand here and say rdma-core user space
support is required for a driver to exist in the RDMA tree? I don't think
that should be a requirement, but certainly there needs to be a consumer of
this. Be it libfabric or kernel ULP, something.
I'm saying someone *at least* needs to do all the driver ABI structure
checks that we do in rdma-core.
.. and absolutely, if the driver implements kernel verbs/common verbs
there must be a rdma-core verbs provider for it as well. I don't think
that is unreasonable.
Completely agree on that.
The question here is if we should even allow drivers under
drivers/infiniband that don't even implement common verbs, like usnic.
I would have been on board with that in the past but these days I'm not
so sure. I would like to see us moving away from an "infiniband"
subsystem to an "rdma" subsystem and embrace other technologies. We
really do need to rename the subsystem at some point.
As far as usnic, it seems like its the driver that has been forgotten
about. I see 3 commits in 2018. I'm not saying it's important or not,
that's another debate for another thread.
But for the EFA driver I'm happy to see it. I say treat this as RFC for
now until we see a libfabric or kernel ULP, or even some other open and
available user space solution.
-Denny
