Hey,
Hello all,
This RFC allows device drivers to indicate their support for in-kernel API
through a flag in the IB device.
Currently, devices that do not support in-kernel APIs (such as usnic) have no
way to communicate that to the ULPs which try to use the device and fail.
Instead, make the driver advertise its support upfront and allow clients to
exit gracefully in case of unsupported device.
Patch #1 adds the flag to the IB device, sets all existing drivers as kernel
verbs providers and chanes the IB clients.
Patch #2 changes usnic driver to a non-kernel verbs provider as it offers no
kernel API support.
This RFC is introduced following the discussion over the EFA driver [1], which
initially does not provide in-kernel API support.
[1] https://patchwork.kernel.org/cover/10711629/
Having some drivers support kernel verbs and others not is confusing to
Linux RDMA users. If we add a kverbs_provider flag then that means that we
officially support that not all drivers support kverbs. I don't like this -
I think new RDMA drivers should support both kverbs and uverbs.
+1, and I'm not sure that we came to any meaningful conclusion that we
allow drivers without kverbs, do we?
I think that the discussion is a bit backwards and so is the RFC..
Its not that EFA does not support kverbs, isn't kverbs is an abstract
name for "what our current ulps require"?
Why is this kernel specific anyways? The exact same holds for uverbs
applications that use RC, or in other words we can also see a kernel
consumer that use UD (and does not rely on IB addressing like ipoib)
that can run on the EFA device...
Perhaps an rdma device needs to specify mask of which QP types it
supports such that the core or the consumer can look at if it wants to
log a meaningful error message (or it can simply fail ib_create_qp).
And, fwiw, I'm not sure I understand why should a new device support our
kernel ulps (again, not kverbs, functionality required by our existing
kernel consumers) if its users are not interested in it (if it was the
case then it would probably be supported). Isn't it enough that
something like rsockets can run on a device to justify its existence?
