On Tue, Jan 01, 2019 at 08:01:39AM -0800, Bart Van Assche wrote: > On 1/1/19 1:30 AM, Gal Pressman wrote: > > 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? > > What is so hard about adding kverbs support to the EFA driver? It is not hard, but they don't need it and won't test it and probably won't care to support it too. So, this series returned us to square one, to discussion if EFA belongs to drivers/infiniband/ or not. Thanks > > Bart.
Attachment:
signature.asc
Description: PGP signature
