[Ofa_boardplus] Voteable item for Thursday's Board Meeting

[Bernard Metzler]

Hi Doug,

Many thanks for the detailed reply. Much appreciated.

Sorry to hear about your trouble to format the reply as intended
- so please let me switch to plain ASCII, inserting comments
accordingly (I prefer that anyway). I deliberately prepend another
'>' to my original text to fake ASCII history.

-----Doug Ledford <dledford at redhat.com> wrote: -----

>To: Bernard Metzler <BMT at zurich.ibm.com>, Paul Grun <grun at cray.com>
>From: Doug Ledford <dledford at redhat.com>
>Date: 03/14/2018 06:11PM
>Cc: "ofa_boardplus at lists.openfabrics.org,"
><ofa_boardplus at lists.openfabrics.org>
>Subject: Re: [Ofa_boardplus] Voteable item for Thursday's Board
>Meeting
>
>I'm sure Paul will probably write something more meaningful than I
>will here, but my answers are inline below:
>
>On Wed, 2018-03-14 at 17:27 +0100, Bernard Metzler wrote:All,
>>I have to admit I did not actively contribute to the mission
>>statement discussion for some time. But let me share with you what I
>>think when I just read the proposed new mission statement.
>>
>>It would reflect quite a big change of the mission of the OFA. To me,
>>old keywords were
>> open source software development, test, licensing, support
>>vendor independence
>>unified, cross-platform, transport-independent software stack for
>>RDMA
>>standards-based software
>>
>>
>>So, to my understanding, the current mission of the OFA is to develop
>>and maintain an ecosystem to ease and promote the usage of RDMA
>>fabrics, while closely following given standards.
>
>I would argue that that mission has been met.  To stick with that
>mission now has little to no meaning, aside from maintaining the
>already written software stack.  But, regardless of the old mission
>statement, the OFA has done more, and will continue to do more, than
>just what this embodies.  Hence, the need for a new mission statement
>and the bylaw rewrite.
>
I came into OFA late, in a phase where the RDMA ecosystem
was already maturing, I don't know much about the early years.
Maybe, OFA now has just fulfilled its original mission and can
declare victory? That software stack now lives in Linux, and it would
likely stay there if OFA would no longer exist. In
that respect, the scope of OFA may change to an influential
role.
But, in any case, I understand that there is a role change.

>>
>>Here are my main concerns with the proposed new mission statement:
>> It  completely lacks the term 'open source software', which was
>>essential for the success of OFA so far.
>>
>
>No one disagrees that open source is certainly the preferred means of
>writing software (although it wasn't the only one the OFA
>used...after all the early RDMA stack was dual licensed GPL/BSD just
>so it could be used in proprietary software, and for a long time OFED

Right, it was open source with a focus on widespread usability.
It was meant to be as minimum restrictive to deploy as possible. We shall
stick to that policy and make it explicit. The mission statement shall 
reflect common agreements, and not assume them implicitly.

>shipped proprietary bits).  But the mission statement is trying to be
>more general than just the software OFA members produce.  It's trying
>to state that the OFA is trying to advance both the hardware the
>stack runs on (be that IB, OPA, standard IP with DCB extensions, or
>just TCP) and the software.  Part of getting the technology more

How can we want to advance hardware - as an alliance including
vendors of different, and potentially even competing hardware.
That sounds tricky. Our role here might better be to get all vendors
on the table to stay committed to certain interfaces, and evolve
them together, to meet common needs. IMHO, this alliance does not
need to become more hardware focused, but more application/user
focused.

To achieve that, for the software part of it we have a lever called
'open source'. No closed software, please. For hardware it is open
interfaces, if not better also open fabrics protocols. Yes, I
speak from a user and/or system integrator view point. 


>ubiquitous is to get more people to write to the APIs, and part of
>that is things like enabling soft RoCE and soft iWARP so it can even
>be used where no hardware support is present.  In the end, that leads
>to a more vibrant ecosystem overall, and actually helps promote more
>hardware uptake on top of just the software uptake.  So, while open
>source software is a key component still, the mission statement was
>intentionally more broad to cover the hardware (which is almost
>always *not* open source).

Right, we do not care much about the etchings on the silicon.
We better care about open driver interfaces and APIs, and hope for
(but we obviously cannot completely control that) standardized wire
protocols.

>>
>>Vendor independence got dropped, transport (fabric) independence as
>>well. 
>>
>
>We have passable vendor independence and transport independence
>already in libibverbs, and even better in libfabrics.  I don't see
>that regressing, as it would negatively impact the advancement of the
>technologies and adoption.  So, it can be assumed simply by the fact
>that we are trying to drive adoption and uptake and not splinter the
>market.
>
I agree, but why we are dropping mentioning it? It is essential,
even if it is obvious.

>> Positioning OFA as a standardization body ("creating industry
>>standard specifications"). That shall be out of scope of OFA.
>>
>>

>Most people thought so.  And although the libfabric API has not been
>defined in your typical IEEE type paper spec, it is a defacto API
>that was grown 100% in house by OFA members.  So we've already done
>the work, it's time to make the fact that we are willing to do the
>work official.
>>
>>"accelerate the development ... of advanced networks" - OFA shall
>>not, and cannot develop new networks, except social ;)
>
>
>See above about trying to get the software in more use.  Also,
>providing the infrastructure in the kernel for quickly adding new
>drivers or new link layers as they come available does accelerate the
>development of the networking technologies themselves.  I have no

I agree it does. 

>doubt that if the RDMA stack didn't exist, then OPA would not yet be
>being deployed in production.  It is a formalization of what we are
>already doing.

I think we always did that, it was always part of OFA activities
to develop a software stack where vendors can plug in their drivers,
since adhering to well defined interfaces. We as OFA promote hardware,
which adheres to our commonly agreed interfaces.

>>
>>"incubating new software technologies" - what is this about? What is
>>an example new software technology which gets incubated in OFA?
>>
>>
>>In a nutshell, it would move the role of OFA from an enabler of
>>technology to a creator and promoter of technology. Of course, the
>>mission statement shall not preclude the adoption of new
>>technologies, best under the umbrella of vendor and transport
>>independence, but its development and promotion shall be outside the
>>scope of OFA.
>>
>>Looking forward to talk to you tomorrow,
>>
>
>(mailer won't let me reply between your last point and your
>summary...and last time I tried to force it, it crashed the reply, so
>just pretend I'm inserting this after your last bullet)
>
>Again, libfabric has already been incubated by the OFA.  That one was
>done from scratch.  It's also been pointed out that the OFA incubated
>the initial libibverbs.
>
>As for your last summary statement, I would only say that the
>development and promotion of new technologies has already been
>happening.  This change in mission statement only makes official what
>is already unofficially done.  I don't see it as outside the scope of
>the OFA at all.

Technology vendors want to promote their technology and for that
benefit from the environment OFA provides. Which is good, and one
part of the success story of OFA. But, again, OFA promotes technology
which adheres to our interfaces (as we develop them). OFA does no
promote (hardware) technology per se.

>
>-- 
>Doug Ledford <dledford at redhat.com>
>    GPG KeyID: B826A3330E572FDD
>    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57
>2FDD
>
[attachment "signature.asc" removed by Bernard Metzler/Zurich/IBM]

Best regards,
Bernard.