Re: Upcoming libibverbs release

Doug Ledford
2016-06-29T20:40:15Z

[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]

On 06/29/2016 03:27 PM, Jason Gunthorpe wrote:
> On Wed, Jun 29, 2016 at 02:15:46PM -0500, Steve Wise wrote:
>
>>> I think you start by realizing that nobody uses your git releases
>>> anyhow.
>>>
>>
>> Not true. RedHat, for one, does.
>
> I mean no users.
>
>>> Everyone uses either a distro or OFED release and those are already
>>> co-ordinated outside your control.
>>
>> I don't know who "everyone" is, but at least some of the distros get
>> the
>
> everyone = users

Jason's point, which is correct, is that even though libcxgb3/4 are
separate from libibverbs in their releases, Red Hat (and presumably
other distros), which are the main bodies that take the individual
tarballs, then coordinate between libibverbs and the plugin libraries
before each of our releases. So your releases are easy for you, and
that gets them directly in the hands of people like Red Hat, but then
they are still coordinated against libibverbs behind the scenes.

>> libcxgb3/4 packages from releases I publish and announce on
>> linux-rdma. Chelsio recommends to RedHat exactly which libcxb
>> release to pull in for each of their OS releases. They are not
>> necessarily tied to an OFED release either. Ditto for SUSE,
>> although they may still take from OFED packages.
>
> And that doesn't really change, you just recommend a libibverbs
> release or libibverbs patch.

Pretty much.

>> From what I've experienced, the distros don't take patches for
>> libraries at all. They take discreet releases that are published by
>> the maintainer of that
>
> Your view might be a bit specialized because a plugin 'library' is a
> very special case. Generally the distros will have tight controls on
> library updates to guarentee no change to the ABI/API. Often they
> won't accept new upstream library versions at all, instead only
> backporting necessary fixes.

Correct, for non-RDMA or kernel related packages. For the entire RDMA
stack and for specific kernel related packages (like ethtool for
instance), the guidelines are different.

> For instance, if you add the new CQ API support the libcxgb (or any
> new API for that matter) then the provider will no longer compile on
> the RH released libibverbs and either Doug will have to work on a
> backport basis, or you will have to jump through configure hoops to
> make it compile.

That's where the special nature of the RDMA stack comes in to play.
Realistically here, we would batch up the libibverbs update that creates
the API plus all of the driver updates to use the API into one release
and the RPM headers for the various packages would Require: the latest
versions of things and simultaneously Conflict: against old releases of
any packages. That way we can enforce an all-or-nothing install of
matching verbs packages.

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

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