Hey Sagi, On 02-Jan-19 02:27, Sagi Grimberg wrote: > 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... Makes sense. > > 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). Supported QP types for the device sounds good. This could both move a chunk of drivers qp types checks to the core and help clients identify an unsupported device. > > 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? Exactly, we just need a proper way to let the ulps know the device does not provide the required functionality.
