[Ofa_boardplus] Voteable item for Thursday's Board Meeting

Wed Mar 14 17:33:42 PDT 2018

Bernard – This is a great discussion, and exactly the kind of discussion we need to have.  You are correct that the proposed mission statement reflects a big change in the OFA’s mission – but it’s a change that has already happened.  What we are doing is making the mission statement reflect that change.
-Paul

From: Doug Ledford [mailto:dledford at redhat.com]
Sent: Wednesday, March 14, 2018 10:12 AM
To: Bernard Metzler <BMT at zurich.ibm.com>; Paul Grun <grun at cray.com>
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:
[PG>>] Doubtful, but that won’t stop me from trying.

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.
[PG>>] If you take the long view, the verbs software stack is now out of the hands of the OFA.  One could argue that it has been successfully adopted by the Open Source community.  So I agree with Doug that we achieved our original mission.
But while that was happening, we seem to have discovered that the OFA has an on-going role.

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 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 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).
[PG>>] The term ‘open source software’ clearly applied while the OFA was in the process of creating the so-called OpenFabrics Software stack, which, as noted above, we no longer control.  Note that one of the items included in the slide deck for discussion tomorrow is exactly the question you raise – Do we need to include the expression, “open source software” in our mission statement, given that our mission seems to have moved beyond the writing and maintaining of OFS.

  *   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.
[PG>>] I would have no objection to adding the expression, “transport independent” to the proposed text.  In my mind, OFI’s ‘transport agnostic’ model is the right approach.

  *   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 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.
[PG>>] The proposed mission statement says that we want to *accelerate*, not develop.  The way we accelerate is by creating new (transport agnostic) software technologies.  I have to go back to two of the four basic elements of a mission which are ‘what value do we deliver’, and ‘how do we deliver that value’.  The value is in accelerating development and adoption; how we do it is by incubating new (transport agnostic) software technologies.

·        "incubating new software technologies" - what is this about? What is an example new software technology which gets incubated in OFA?
[PG>>] libibverbs, libfabric
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.

[PG>>] The word ‘incubate’ is used intentionally to reflect the reality that anything successfully developed (‘incubated’) in the OFA is almost certain to eventually end up in open source, exactly as happened with ibverbs.
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.

--
Doug Ledford <dledford at redhat.com<mailto:dledford at redhat.com>>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofa_boardplus/attachments/20180315/adefe33d/attachment.html>