Re: Upcoming libibverbs release

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2147 bytes --]

On 6/29/2016 2:30 PM, Jason Gunthorpe wrote:
> On Wed, Jun 29, 2016 at 08:19:56AM +0300, Leon Romanovsky wrote:
>> On Tue, Jun 28, 2016 at 09:26:38PM +0000, Hefty, Sean wrote:
>>>> The fundamental question is if it is acceptable for libibverbs to ship
>>>> a new core provider agnostic API (cq polling) that is optional
>>>> depending on provider.
>>>>
>>>> I say no, that is not acceptable.
>>>
>>> I agree - there's no compelling argument that the new calls can't work over all providers.
>>
>> I agree too, this is why code is provided and nothing stops from other provider to support it.
> 
> That isn't what I said, and it isn't what everyone is agreeing with.
> 
> I said an optinal API is not acceptable to ship.
> 
> That means 'nothing stops' is not enough - the patch author and
> maintainer have the responsibility to ensure all providers work with
> the API before shipping it.

That's not entirely true.  In the kernel, if someone cuts over stuff
from one API to a replacement API, then yes, they are responsible for
updating all of the users of the old API.  But if they create a new API
that is in addition to the old API, then that's not the case.  This
falls in that latter category.

That said, there is no reason that owners of various driver libraries
can't update their own libraries to this API.  As we already discussed
in another thread when Steve Wise brought up the issue of how things
would look if we put the providers into the same package as libibverbs,
distros and such have their own schedules and the day we release
something here is not the same day they pick things up there, so we
should have sufficient time to update libibverbs and then cut over the
driver modules.  They don't have to happen on the same day.

What I don't want is a core compat layer in libibverbs.  The changes
needed to support just the pull cq changes are not that drastic and they
have benefit that would be lost in a compat layer, so I would rather see
them done natively on a per library basis.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]