Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[richard Croucher <Richard.croucher-jNDFPZUTrfRJpuwtbJ71GdBPR1lH4CV8@public.gmane.org>]

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

I could not echo this point more.  I principally work with Enterprise
clients.  None use custom kernels and all are dependent on the support
provided from their Linux distro vendors.  
We have repeatedly ended up in finger pointing exercises where RDMA
 vendors insist on us using their drivers and the Linux distro vendor
want us to use there's.   The customer always loses in these
situations.
Only as an absolute last resort we will use proprietary drivers,
 modules  and system libraries because we know it will compromise
support and may hit us later.
Certain vendors try to do this under the radar  now replacing all sorts
of distro system libraries when you innocently install their Ethernet
driver.  Doing it surreptitiously rather than blatantly is not the
answer.   Get your code into mainline and work with the major distro
vendors on the backports and updates.
I continually face resistance from Enterprise accounts in adopting RDMA
in a more widespread manner.   It's the perception of the risk raised
by the Linux SA's in supporting these systems.    I needs to just
'work' running only the standard distro installers to add it if it is
not there by default. 
On Thu, 2017-05-04 at 20:42 -0700, Jim Foraker wrote:
> On 05/04/2017 10:34 AM, Hefty, Sean wrote:
> > 
> > > 
> > > This is exactly why we so strongly discourage this out of tree
> > > stuff - getting something unmergable in OFED is *NOT* Job Done,
> > > Time to Go Home. Down this path just creates another Lustre mess.
> > Actually, this may be 'job done'.  No individual or company is
> > obligated to provide upstream software for any of their hardware.
> > OFA decides what to ship in their software products, not the
> > greater
> > linux kernel community.  Individual companies can decide if out of
> > tree maintenance is more cost effective than trying to merge code
> > upstream.  Because that's what this ultimately comes down to.
> > 
> > IMO, the only people who have legitimate complaints here are those
> > people running Xeon Phi with Mellanox HCAs who are being forced to
> > use OFED, rather than upstream code.
>       Apparently we've experimented with doing just this, so I'll
> bite. 
> And I will say the same thing we've told every vendor repeatedly:
> "get 
> your code upstream!"
>       A vendor may weigh the cost of maintaining out-of-tree code
> versus 
> upstreaming it, but as a customer, I'm more concerned about the 
> annoyance and time wasted having to run N different software stacks
> on N 
> different hardware types versus being able to use the RDMA stack from
> my 
> preferred linux distribution everywhere.  And the best way to get
> your 
> code into the distributions is to get it upstream.
>       I have no particular opinion on whether or not the xeon-phi
> driver 
> belongs in OFED.  But cloaking this conversation in talk of
> obligations 
> and framers' intent misses a bigger point, which is that any code
> not 
> fully upstreamed, and hence likely to be found in your user's
> distro, 
> inconveniences them, increases their support costs, and makes it
> less 
> likely that they will adopt your product.
> 
>       Jim
> _______________________________________________
> ewg mailing list
> ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org
> http://lists.openfabrics.org/mailman/listinfo/ewg
-- 

Richard Croucher
www.informatix-sol.com


[-- Attachment #1.2: Type: text/html, Size: 4106 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/mailman/listinfo/ewg