<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>On Thu, 2017-05-04 at 20:42 -0700, Jim Foraker wrote:</div><blockquote type="cite"><pre>On 05/04/2017 10:34 AM, Hefty, Sean wrote:
<blockquote type="cite">
<blockquote type="cite">
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.
</blockquote>
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.
</blockquote>
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
<a href="mailto:ewg@lists.openfabrics.org">ewg@lists.openfabrics.org</a>
<a href="http://lists.openfabrics.org/mailman/listinfo/ewg">http://lists.openfabrics.org/mailman/listinfo/ewg</a></pre></blockquote><div><span>-- <br>
<meta http-equiv="Content-Type" content="text/html; CHARSET=UTF-8">
<meta name="GENERATOR" content="GtkHTML/4.6.6">
<br>
Richard Croucher<br>
<a href="http://www.informatix-sol.com">www.informatix-sol.com</a><br>
<br>
</span></div></body></html>