Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Wed, Aug 31, 2016 at 05:40:07PM +0000, Woodruff, Robert J wrote:

> If everything is bundled together, it makes providing incremental
> updates very problematic.  For example, say vendor A needs to
> distribute a simple bug fix in their code to a customer so they make
> a copy of the bundled package, add their fix and give it to a
> customer. Seems simple, right ?  But then vendor B has a similar
> situation and distributes a package with only a fix to their
> library, but when the customer Installs it, it overwrites the
> package provided by vendor A and removes their bug fix.  This kind
> of thing will end up as a huge disaster for customers and vendors
> that are trying to support their customers.

Erm, but we already have a mess. AFAIK Mellanox and Intel both use
OFED derivatives as their main means to deliver fixes to customers
that both entirely replace the distro stack and completely conflict
with each other.

So, I'm sorry, I see your scenario as complete fiction today. We are
certainly not making it worse for anyone.

One the contrary, as I pointed out to Mellanox and Chelsio, Intel has
the same problem getting wide distribution of their provider. Is hfi1
even in Fedora yet? Only thing I found was that it was blocked by
review:

https://bugzilla.redhat.com/show_bug.cgi?id=1315870

Let alone Debian..

So, again, your world view of 'rapid updates' seems like a complete
fiction if you have been trying for half a year to enter the
distribution channel. How can you possibly call that a success???

At least ipathverbs seems uniformly distributed in Fedora and Debian,
kudos on that. (though it hasn't changed since 2014, but your release
process is not creating version tags in github, oops)

This would not be such a problem with rdma-plumbing as Fedora would
seemlessly track upstream and all providers from all vendors would
trivially enter the distribution when they regularly pick up the new
upstream. Vendors would no longer have to individually have go to each
distro and lobby for inclusion.

You, again, have missed the major point. Publishing some random code
on a random github is not really distribution. It is not reaching end
users, it is not working effectively. It doesn't matter how quickly
you can update your own vendor private github if the distros simply
ignore it.

IMHO, there is no 'update' until a vendor's provider reach an end user
through their preferred distribution.

> 2.) Allow a vendor the ability to distribute their library package
> separately from the bundled package.

There is nothing stoping this, it is trivial for the vendor to make a
.spec file for rdma-plumbing that just produces a rpm with the single
vendor provider (after doing the full build).

If you really want an example I will show you.

> 3.) Allow the ability for a vendor to distribute an update package
> that just contains their library code to replace the version of that
> code that is in the bundled package. I think that OFI, for example,
> has something like this to avoid this kind of mess.

Certainly, we can make this even easier as well. Mainly what is needed
is some way for the vendor to drop in a override .driver file in
/etc/ibverbs.d/

It would not be hard to make a patch that does that, if that is all it
takes to alleviate your concern I can add it to the todo list.

BTW, it is bit rich to laud Sean for bundling drivers with libfabric
and condem us for doing the same with libibverbs :(

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html