Re: [PATCH RFC 0/2] IB device in-kernel API support indication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux