<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.im
{mso-style-name:im;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">We have had some discussions with the distro’s (both Redhat and SUSE) to explore the possibility for the OFA and the distro’s to work closer together.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">One of the things we discussed was having the distros be able to test early versions of distro releases in the UNHIOL testing lab so that if there
<br>
are any interop issues, they could be fixed before the distro version releases. This would require the distros to provide early drops of their code to UNH-IOL<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">similar to the arrangement they have with certain vendors. This might allow the in-box distro code to be used for OFA interop logo testing in the future, rather
than <br>
using the community OFED, which they do now. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think where we left it was that the distros were off contemplating it and perhaps also thinking about joining the OFA to facilitate that closer relationship.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Note also that we have been clearly communicating for some time now, that for most production users, they should use the in-box versions of OFA code whenever
possible<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">and only need to install and use the community OFED if they need something that may be in OFED that is not yet in the distro, which is becoming a smaller<br>
and smaller set of things every day. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">My 2 cents.<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ofa_boardplus [mailto:ofa_boardplus-bounces@lists.openfabrics.org]
<b>On Behalf Of </b>Christoph Lameter<br>
<b>Sent:</b> Tuesday, May 16, 2017 2:09 PM<br>
<b>To:</b> Paul Grun <grun@cray.com><br>
<b>Cc:</b> ofa_boardplus@lists.openfabrics.org<br>
<b>Subject:</b> Re: [Ofa_boardplus] OFED releases<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Note that Jason also says that the sites are also actively working on getting stuff submitted upstream to minimize their delta as well as working with the distros to make sure things are straight. We have done that as a company but I do
not see OFED do this. If OFED would work in a collaborative way with distros and upstream to ensure that the distros include the necessary changes then that would be a good thing. One of the key things then will have to adopt the methods and processes to work
with upstream and the distros and to interact with them in a regular fashion,.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, May 16, 2017 at 12:48 PM, Paul Grun <<a href="mailto:grun@cray.com" target="_blank">grun@cray.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">>The only avenue left is a technical solution - someone has to fund the work to<br>
>actually go and create a fork that matches what the sites need, pulling from the<br>
>vendor forks, and do this faster than the upstream process would get it done.<br>
<br>
Would it be unreasonable to think of the EWG as being the technical body that could do what Jason suggests?<br>
<br>
<span class="im">>-----Original Message-----</span><br>
<span class="im">>From: Ofa_boardplus [mailto:<a href="mailto:ofa_boardplus-bounces@lists.openfabrics.org">ofa_boardplus-bounces@lists.openfabrics.org</a>] On</span><br>
<span class="im">>Behalf Of Jason Gunthorpe</span><br>
<span class="im">>Sent: Thursday, May 11, 2017 4:05 PM</span><br>
<span class="im">>To: Atchley, Scott <<a href="mailto:atchleyes@ornl.gov">atchleyes@ornl.gov</a>></span><br>
<span class="im">>Cc: <a href="mailto:ofa_boardplus@lists.openfabrics.org">ofa_boardplus@lists.openfabrics.org</a></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">>Subject: Re: [Ofa_boardplus] OFED releases<br>
><br>
>On Thu, May 11, 2017 at 09:44:11PM +0000, Atchley, Scott wrote:<br>
><br>
>> Again, I am not arguing for a change in anyone’s workflow from pushing<br>
>> upstream first. But while upstream debates implementation and while<br>
>> the eventual design works its way to the distro backports, what should<br>
>> users do with hardware on their floor?<br>
><br>
>They need to use the fork of the software that vendor provides. There is no other<br>
>answer. Only the vendor is going to be willing to support and develop that forked<br>
>code.<br>
><br>
>Your #2 problem is the real intractable issue.<br>
><br>
>The upstream neutral collaborative process is how we have been successful in<br>
>getting the vendors to work together, at all. That has become an industry wide<br>
>defacto agreed upon way to work on a shared code base.<br>
><br>
>There is no way, politically, to just short circuit that process and keep the vendors<br>
>engaged.<br>
><br>
>It isn't reasonable to ask the vendors to union their forks of the RDMA stack<br>
>outside of the upstream process - there are overlaps and disagreements, this<br>
>would create a different layer of arguing. As a group, the vendors have no<br>
>incentive to do that.<br>
><br>
>The only avenue left is a technical solution - someone has to fund the work to<br>
>actually go and create a fork that matches what the sites need, pulling from the<br>
>vendor forks, and do this faster than the upstream process would get it done.<br>
><br>
>Frankly, this is what all the big cloud operators do internally - they fund a kernel<br>
>and infrastructure development team to mangle the software into the shape they<br>
>want, and upstream things to minimize their maintenance cost.<br>
><br>
>Jason<br>
>_______________________________________________<br>
>Ofa_boardplus mailing list<br>
><a href="mailto:Ofa_boardplus@lists.openfabrics.org">Ofa_boardplus@lists.openfabrics.org</a><br>
><a href="http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus</a><br>
_______________________________________________<br>
Ofa_boardplus mailing list<br>
<a href="mailto:Ofa_boardplus@lists.openfabrics.org">Ofa_boardplus@lists.openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>