[rdma-next,v6,0/2] IB device in-kernel API support indication

Message

Gal Pressman Jan. 22, 2019, 8:08 a.m. UTC

Hello all,
This patchset marks drivers that do not implement all mandatory verbs for
kverbs as non-kverbs providers through a flag in the IB device.  Currently,
ULPs add the device and fail when trying to make actual use.  Instead, in case
of missing verbs, mark the device as a non-kverbs provider and allow clients to
exit gracefully.

This also removes the need for stubs implementation of unsupported verbs, which
will no longer fail the device registration but mark the device as non-kverbs
provider.

A 'no_kverbs_req' flag is added to the ib_clients, which is off by default
except for uverbs. This is added in order to identify the uverbs module when
registering a new device/client.
It can also be done using name comparison but the flag seems better to me.

Patch #1 adds the flag to the IB device and marks devices that do not implement
all needed kverbs functions.
Patch #2 removes all stub functions from usnic.

This patchset 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/

Changelog:
v5->v6
* Drop NULL checks from device registration
* Change kverbs_provider flag to u16 (was u8)
v4->v5
* Move the client addition check to add_client_context to prevent code duplication
v3->v4
* Typo fixes
* Remove unnecessary function pointers NULL checks
v2->v3
* Remove warning print when mandatory verb is not implemented
* Change comment of no_kverbs_req flag
* Add NULL checks for callbacks in unprotected flows
v1->v2
* Make core code mark devices instead of having each driver advertise its support
* Prevent clients device addition in core code instead of inside the clients

Thanks,
Gal

Gal Pressman (2):
  RDMA: Add indication for in kernel API support to IB device
  IB/usnic: Remove stub functions

 drivers/infiniband/core/device.c             | 10 +++---
 drivers/infiniband/core/uverbs_main.c        |  1 +
 drivers/infiniband/hw/usnic/usnic_ib_main.c  |  7 ----
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 53 ----------------------------
 drivers/infiniband/hw/usnic/usnic_ib_verbs.h | 15 --------
 include/rdma/ib_verbs.h                      |  5 +++
 6 files changed, 12 insertions(+), 79 deletions(-)

Comments

Jason Gunthorpe Jan. 31, 2019, 3:36 a.m. UTC | #1

On Tue, Jan 22, 2019 at 10:08:21AM +0200, Gal Pressman wrote:
> Hello all,
> This patchset marks drivers that do not implement all mandatory verbs for
> kverbs as non-kverbs providers through a flag in the IB device.  Currently,
> ULPs add the device and fail when trying to make actual use.  Instead, in case
> of missing verbs, mark the device as a non-kverbs provider and allow clients to
> exit gracefully.
> 
> This also removes the need for stubs implementation of unsupported verbs, which
> will no longer fail the device registration but mark the device as non-kverbs
> provider.
> 
> A 'no_kverbs_req' flag is added to the ib_clients, which is off by default
> except for uverbs. This is added in order to identify the uverbs module when
> registering a new device/client.
> It can also be done using name comparison but the flag seems better to me.
> 
> Patch #1 adds the flag to the IB device and marks devices that do not implement
> all needed kverbs functions.
> Patch #2 removes all stub functions from usnic.
> 
> This patchset 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/
> 
> Changelog:
> v5->v6
> * Drop NULL checks from device registration
> * Change kverbs_provider flag to u16 (was u8)
> v4->v5
> * Move the client addition check to add_client_context to prevent code duplication
> v3->v4
> * Typo fixes
> * Remove unnecessary function pointers NULL checks
> v2->v3
> * Remove warning print when mandatory verb is not implemented
> * Change comment of no_kverbs_req flag
> * Add NULL checks for callbacks in unprotected flows
> v1->v2
> * Make core code mark devices instead of having each driver advertise its support
> * Prevent clients device addition in core code instead of inside the clients

Applied to for-next thanks

Jason