On 01-Jan-19 18:01, 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. > > What is so hard about adding kverbs support to the EFA driver? > > Bart. Hi Bart, This RFC is sent in order to help prevent the confusion; there's already a driver that doesn't support kverbs which instead of having a proper way to advertise that, simply fails the kernel callbacks. Informing the ib clients upfront seems like a more healthy behavior to me. For the RDMA users, I can add a sysfs/rdma tool indication that will make it clear whether the device supports kernel verbs or not, does that sound reasonable? EFA supported QP types are UD and Scalable Reliable Datagram (SRD, driver QP type). Since kernel verbs do not make use of either of those QP types we do not support in-kernel APIs initially.
