[Ofa_boardplus] Draft Mission Statement

[Doug Ledford]

On Thu, 2018-03-15 at 18:17 +0000, Paul Grun wrote:
> Rather than adding to the existing thread, I would ask the thread
> contributors to reprise their comments in light of the following
> draft mission statement:
> 
> “The mission of the OFA is to accelerate the development and
> adoption of advanced networks for the benefit of developers and
> consumers of such networks by incubating new, (vendor independent),
> software (stacks?) (technologies?) for fabrics, (creating industry
> standard specifications,) evangelizing existing and emerging
> technologies, and by evolving and supporting existing software for
> fabrics.”
> 

Thanks for sending this out Paul.  There were some comments on the call
that we ran out of time to address, so I'd like to take a stab at one of
them here:

What does "advanced networks" even mean?

So, I had originally suggested we use "RDMA enabled networks" and that
got shot down because there is an existing assumption, right or wrong,
that RDMA equates to IB.  The term advanced networks was really meant to
encompass any network setup that enables what we would traditionally
think of as common RDMA functionality.  So, for instance, IB and OPA are
certainly in there, but we can also run RDMA functionality over standard
Ethernet using iWARP, or RoCE with a lossless Ethernet, or RoCE with ECN
enabled on the Ethernet.  But any of these Ethernet solutions require
additional software/hardware to make them work (a soft RoCE or soft
iWARP driver, or actual RoCE/iWARP hardware, and in some cases specific
abilities in the switches), so that's what earns them the moniker
"advanced networks", because they *are* more advanced than a garden
variety Ethernet deployment.  But it was also meant to encompass any new
fabrics that might come around in the future assuming they are a good
fit for the OFA stacks.

This then brings up the point, "What is a good fit for the OFA stacks?"

I've tried to pin down the essence of this.  After a lot of thought, I
think the core, defining element of what is a good fit for the OFA
stacks is any technology that enables application direct network I/O (ADNIO I guess?).  You can't say "it must be RDMA capable" because not everything we support is truly RDMA (USNic for one, but even just the verbs API has non-RDMA components in that post_send/recv are not truly RDMA operations, but instead are merely application direct I/O).  This is the thing that separates us from the Berkeley sockets programming model more than anything else and catches what all of our current implementations do, either in hardware or software.

All the way back in 2006 I gave a talk at the Red Hat Summit about
InfiniBand and RDMA.  As I was explaining how it differed from regular
networks, I used the analogy that for normal Berkeley sockets type
networks, there is a pipe that comes in and the kernel is like a mailman
at the post office, taking all of the data off that pipe and then
sorting it into PO Boxes.  When a PO Box gets data, he rings the box's
owner, and then the owner comes by and they photocopy the data for the
owner, then shred the original.  What our fabrics do, is bypass that
kernel sorting and PO Box behavior entirely.  Instead of one pipe coming
in and the kernel dealing with it, each would be PO Box owner gets their
own pipe(s) and the data is dropped directly in their lap with the
kernel never being involved.  I think this is really the core, defining
characteristic of what we support is all about.  Whether the pipes are
queue pairs, or fabric endpoints, or a virtual NIC with our own MAC
address so that all packets to our MAC come directly to us, that's all
implementation details.  The core feature is Application Direct Network
I/O.

Also, people had some problems with the verbage "accelerate the
development".  Personally, I would love for the OFA's actions to
accelerate actual ADNIO usage, but the benefit for development is just a
side effect of the existence of the current stacks, so I could see
leaving development out.  And the term "accelerate" was used versus
other terms (such as "aid") because we are trying to evangelize the
technologies to groups that don't currently use them and that would
indeed accelerate their deployment.

So, with these things in mind, I think a person could rewrite the first
part from "accelerate the development and adoption of advanced networks"
to "acclerate(aid?) the adoption and deployment of Application Direct
Network I/O enabled networks".  But you see then how the phrase grew
drastically in size, so I'm not sure this is a good change.  But if you
want to know what we were trying to express with the original phrase,
then I think the replacement I've given here is pretty on the mark.

-- 
Doug Ledford <dledford at redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ofa_boardplus/attachments/20180316/397d7d94/attachment.sig>