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

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

On Thu, Sep 01, 2016 at 11:29:21AM -0400, ira.weiny wrote:

> > 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.
> 
> OPA's "delta install" is _not_ based on OFED and installs only the bits which
> are needed beyond what is in the distro.  Many of those changes already appear
> in upstream repos which have not made it into the specific distro version.  As
> things are accepted we drop those bits from our install.  This has been our
> policy for some time and if you look at our IFS download you can see that the
> packages which get installed for newer distros like 7.2 are smaller than
> previous versions.

Cool, I am behind the times on that I guess.

However, the my point remains, it still clashes with what MOFED does,
and the idea of two vendors not stomping on each other is still
ficitional.

> To some extent this supports Woody's position.  libhfi1verbs is being used by
> many customers because we can supply it without breaking the standard
> libibverbs install.  NOTE in Fedora, RHEL, SLES, and others we _do_ _not_
> update libibverbs.  Thus keeping the standard distro support intact for other
> vendors hardware.

Well only in the sense that you are on a path that makes it hard to get
into the distros thus requiring you jump through hoops to distribute
your software..

Lets focus on the actual problem :)

> > > 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.
> 
> That could be an alternative.
> 
> > 
> > > 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.
> 
> Agreed.  FWIW I would just add such external updates to an "updates" directory
> so that users can easily see that something extra was installed.  But this is a
> minor point.

I'll write a patch to enable 'run from build' in a way which should
make this even more straight forward.

However, things are already fine today, you just drop your driver in
/opt/intel-opa/lib/libhfi1.so and customize
/etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I
wrote the absolute path patch for this years ago for exactly this
reason)

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