On 02-Jan-19 13:31, Leon Romanovsky wrote: > 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 > My original suggestion doesn't really complicate the ULPs in any way, an additional if statement is not a lot of responsibility. The QP type suggestion does impose a bit more requirements from the ULPs, but it provides them with more flexibility. A ULP that can make use of UD QP type for example, could use devices that he couldn't have if we used the 'kverbs_provider' all or nothing flag.
