On Wed, Jan 02, 2019 at 10:40:52AM +0200, Gal Pressman wrote: > 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. For me it sounds a little bit different. I think that it will complicate ULPs and will push responsibility from driver authors and their employer companies to ULP authors who are not supposed to be spec savvies in order to use kverbs. Thanks
Attachment:
signature.asc
Description: PGP signature
