<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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri",sans-serif;}
span.hoenzb
        {mso-style-name:hoenzb;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@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">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">  Broadcom and Cavium are actively participating in the OFA-IWG, both debug and the current Logo event.    It’s been a productive activity and have identified
 and resolved interop issues, also including the Intel iWarp device Woody mentioned.  Turning out to be a good year for new devices and interop in general.
<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">I’m a strong proponent for increasing UNH-IOL’s contribution relative to more active pre-release testing of both OFED and OS Distros and increasing the focus
 on SW stability. As Woody and Susan have mentioned these are both areas we’re looking to extend thru the new services agreement(s) and budget changes to improve both the value and stability of RDMA.<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">Paul<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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="_____replyseparator"></a><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>Woodruff, Robert J<br>
<b>Sent:</b> Friday, September 01, 2017 10:52 AM<br>
<b>To:</b> Jim Ryan <jimdryan@gmail.com>; Jason Gunthorpe <jgunthorpe@obsidianresearch.com><br>
<b>Cc:</b> ofa_boardplus@lists.openfabrics.org, <ofa_boardplus@lists.openfabrics.org><br>
<b>Subject:</b> Re: [Ofa_boardplus] Logo Program Discussion<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></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">Christoph Lameter wrote,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoPlainText">>Which companies are participating in the IWG? It seems that Mellanox is at this point the overwhelming provider of most of the InfiniBand technology with just minor niches >occupied by others. Our own experience with trying to use technology
 from Qlogic on a single system (2011) failed miserably. Intel is moving to Omnipath. Others simply focus on >Ethernet to have a vendor neutral shared standard.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">>It seems to us therefore (Jump Trading) that there is a trend for interconnect technology to become vendor specific whereas the APIs to access the interconnect (RDMA subsystem >in the kernel) provide a common way of using these fabrics
 by essentially providing a hardware abstraction layer for fabrics in the Linux Kernel.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">>Given this I would like to see a list of participants in the IWG and if its is as dominated as I think it is by Mellanox then we should slowly shut down the program and focus on the >software layer while continuing to provide a forum
 for the exchange of innovative ideas about fabrics.<o:p></o:p></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">Since this discussion has moved to a new thread… Adding my comment here too…<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="MsoPlainText">There are actually a number of new RDMA devices coming on the market recently, such as the new Cavium and Broadcom Roce adapters and the new Intel iWarp NIC that is integrated into the chipset of the recently released Xeon (skylake)
 platform. I know that Intel is still interested in interop testing between the new i40 NIC and the Chelsio iWarp NICs.
<o:p></o:p></p>
<p class="MsoPlainText">I believe that Cavium has also been participating in various debug events. Not sure about Broadcom. Check with Paul Bowden and/or Rupert Dance. They would have the details on who is most active in the events.
<o:p></o:p></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"><o:p> </o:p></span></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 [<a href="mailto:ofa_boardplus-bounces@lists.openfabrics.org">mailto:ofa_boardplus-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Jim Ryan<br>
<b>Sent:</b> Thursday, August 31, 2017 8:48 PM<br>
<b>To:</b> Jason Gunthorpe <<a href="mailto:jgunthorpe@obsidianresearch.com">jgunthorpe@obsidianresearch.com</a>><br>
<b>Cc:</b> <a href="mailto:ofa_boardplus@lists.openfabrics.org">ofa_boardplus@lists.openfabrics.org</a>, <<a href="mailto:ofa_boardplus@lists.openfabrics.org">ofa_boardplus@lists.openfabrics.org</a>><br>
<b>Subject:</b> Re: [Ofa_boardplus] Logo Program Discussion<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Jason, because of my idiot gmail  system, I have to copy/paste your comments below. I apologize for the redundancy this will likely present:<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">> IBTA. We view interop as a program of value to participants who make the biz<br>
> decision to fund it.<br>
<br>
> actual components are, AFAIK, left behind after testing. I have requested<br>
> another call for donations but, for whatever reason, that hasn't happened.<br>
<br>
Ignoring donations, a logo program that pretty much exclusively<br>
certifies discontinued equipment has deeply malfunctioned.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">>>>[JR] if that were the case, I'd have to agree, and I hope it's not. My best info is there are new devices coming in for testing. If that's not the case, I have no defense or further arguments.<span style="font-size:9.5pt"><br>
<br>
> I *do* have to ask you to not use terms along the lines of "membership<br>
> funding"; there is no such thing.<br>
<br>
When I use that term, I am refering to the direct funding from the<br>
membership of the OFA to the OFA treasury in the form of general dues,<br>
IWG particpation fees, special contributions, and sponsorship<br>
opportunities. There certainly is such a thing :)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">>>>[JR] I'm sorry, but I continue to disagree. OFA members make a specific decision to pay dues and they make a separate decision as to whether to pay logo/interop participation fees. I'm asking you to respect that and I'm perplexed as
 to why you want to remove that option from them<span style="font-size:9.5pt"><br>
<br>
> Re the quality of testing, that's a challenge for the IWG. One of, if not *the*<br>
> most important thing they're responsible for is quality of testing. If<br>
> something is broken there, I'm not aware of it, and we need to come to<br>
> understand this.<br>
<br>
As far as granting logos to the submitted devices, it could be<br>
fine.<br>
<br>
As far as testing the OFED software and the open source stack around<br>
it, it is vastly inadequate. I can say that confidently just from the<br>
list of hardware being tested: It simply does not cover a very useful<br>
(to end users) portion of the stack any longer.<br>
<br>
So, again, I would like to see the OFA refocus this funding on better<br>
testing. Scrap the logo program and ask the participating membership<br>
to redirect the funding to direct software stack testing. Test the<br>
software stack. Figure out how to directly buy modern hardware if<br>
donations are not forthcoming. I hope this is the shape of the<br>
discussion that is ongoing with the distros.<br>
<br>
IMHO, this is how to get end-user orgs like RH, suse, LANL, etc to<br>
particpate financially in the testing process.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">>>>[JR] I'm asking you to not lose this train of thought. I think this could be really useful, w/o prejudging the outcome of the discussion. Plz continue<span style="font-size:9.5pt"><br>
<br>
> Finally, I realized I failed to respond to a point you made earlier. It's kinda<br>
> delicate, but important. The OFA is specifically not "chartered" to develop<br>
> specs and the IBTA and others are. There are IP provisions that need to exist<br>
> if this is part of our mission or not. I can give you boring details if you<br>
> want to hear more.<br>
<br>
Yes, as I said, I've argued this semantic point with Paul before ...</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">>>>[JR] yes, again, we've walked this thin line. We can certainly address this as part of our Bylaws review and that, of course, is the right way to address this issue. Please don't give up; this could be extremely important to us<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Jim<br>
<span style="font-size:9.5pt"><br>
I think this is something to fix in the new bylaws..<br>
<br>
> The reason this is delicate is because the OFIWG has had to go right<br>
> to the edge of what we can do, to use MAN pages to document expected<br>
> API functionality. We have agreed this is short of a spec, but you<br>
> get the point; it's a fine but important distinction.<br>
<br>
.. because IP protections exist for a reason. Just because you call<br>
the spec a MAN page, doesn't remove the need to be careful of IP<br>
issues :)<br>
<br>
Safeguarding against IP issues is an important role for an open source<br>
foundation.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">x<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Aug 31, 2017 at 7:13 PM, Jason Gunthorpe <<a href="mailto:jgunthorpe@obsidianresearch.com" target="_blank">jgunthorpe@obsidianresearch.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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">I broke the thread and revised the subject so it is easier to<br>
follow. Thanks for suggesting it Paul.<br>
<br>
On Thu, Aug 31, 2017 at 05:28:04PM -0700, Jim Ryan wrote:<br>
> Ok, I think I see your point. Your consciously blending membership dues with<br>
> interop program participation to make a point. I don't want to argue that<br>
> point, but I do want to be painfully clear about something. The approach we<br>
> take is conscious and, for example, specifically contrary to, for example the<br>
<br>
Yes, I at least, have always understood this is how IWG operates.<br>
<br>
> IBTA. We view interop as a program of value to participants who make the biz<br>
> decision to fund it.<br>
<br>
> actual components are, AFAIK, left behind after testing. I have requested<br>
> another call for donations but, for whatever reason, that hasn't happened.<br>
<br>
Ignoring donations, a logo program that pretty much exclusively<br>
certifies discontinued equipment has deeply malfunctioned.<br>
<br>
> I *do* have to ask you to not use terms along the lines of "membership<br>
> funding"; there is no such thing.<br>
<br>
When I use that term, I am refering to the direct funding from the<br>
membership of the OFA to the OFA treasury in the form of general dues,<br>
IWG particpation fees, special contributions, and sponsorship<br>
opportunities. There certainly is such a thing :)<br>
<br>
> Re the quality of testing, that's a challenge for the IWG. One of, if not *the*<br>
> most important thing they're responsible for is quality of testing. If<br>
> something is broken there, I'm not aware of it, and we need to come to<br>
> understand this.<br>
<br>
As far as granting logos to the submitted devices, it could be<br>
fine.<br>
<br>
As far as testing the OFED software and the open source stack around<br>
it, it is vastly inadequate. I can say that confidently just from the<br>
list of hardware being tested: It simply does not cover a very useful<br>
(to end users) portion of the stack any longer.<br>
<br>
So, again, I would like to see the OFA refocus this funding on better<br>
testing. Scrap the logo program and ask the participating membership<br>
to redirect the funding to direct software stack testing. Test the<br>
software stack. Figure out how to directly buy modern hardware if<br>
donations are not forthcoming. I hope this is the shape of the<br>
discussion that is ongoing with the distros.<br>
<br>
IMHO, this is how to get end-user orgs like RH, suse, LANL, etc to<br>
particpate financially in the testing process.<br>
<br>
> Finally, I realized I failed to respond to a point you made earlier. It's kinda<br>
> delicate, but important. The OFA is specifically not "chartered" to develop<br>
> specs and the IBTA and others are. There are IP provisions that need to exist<br>
> if this is part of our mission or not. I can give you boring details if you<br>
> want to hear more.<br>
<br>
Yes, as I said, I've argued this semantic point with Paul before ...<br>
<br>
I think this is something to fix in the new bylaws..<br>
<br>
> The reason this is delicate is because the OFIWG has had to go right<br>
> to the edge of what we can do, to use MAN pages to document expected<br>
> API functionality. We have agreed this is short of a spec, but you<br>
> get the point; it's a fine but important distinction.<br>
<br>
.. because IP protections exist for a reason. Just because you call<br>
the spec a MAN page, doesn't remove the need to be careful of IP<br>
issues :)<br>
<br>
Safeguarding against IP issues is an important role for an open source<br>
foundation.<br>
<span style="color:#888888"><br>
<span class="hoenzb">Jason</span></span><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>