[ofiwg] for tomorrow's DS/DA telecon

Paul Grun grun at cray.com
Tue Jan 12 02:37:45 PST 2016

I think you're right...we need more discussion. :-)

Disclaimer - as you all know by now, I am not a qualified s/w engineer, hence my use of certain expressions is suspect at best and subject to correction.  That being said, here's how I think of it: 

(BTW, the main OFI WG went through similar agony in defining its terms, so this isn't surprising).

Looking at the original charter for OFI (nee OFWG), it is to: 

Develop, test, and distribute:
1.  An extensible, open source framework that provides access to high-performance fabric interfaces and services.
2.  Extensible, open source interfaces aligned with ULP and application needs for high-performance fabric services.

(Notice how the wording carefully doesn't say "provides access for applications and middleware".  The expression "ULP" in the 2nd bullet was taken directly from the original OFED architecture where things like iSCSI and SRP were described as ULPs.)

OFIWG, because it got there first, defined the framework described in the first bullet as consisting of an implementation of an API and an accompanying set of providers.  The first implementation of an API to emerge was libfabric.  Hence, OFI is the concept, and libfabric is the implementation.

The second implementation of an API to emerge is kfabric.  Hence, I think of kfabric as an implementation of an API, not as an architecture or concept.  Kfabric is analogous to libfabric.

I've brought this up a few times because I'm wondering if we even need the expression kfi at all.  In my worldview, libfabric and kfabric are both spawned from the same high level concept - OFI.

I am willing to be talked out of this (see the disclaimer above). 

-----Original Message-----
From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-bounces at lists.openfabrics.org] On Behalf Of Robert D. Russell
Sent: Monday, January 11, 2016 9:22 AM
To: ofiwg at lists.openfabrics.org
Subject: [ofiwg] for tomorrow's DS/DA telecon


After last week's DS/DA discussion, it is clear that we need to be more consistent and precise in our use of the terms "kfi" and "kfabric".  Below are some of my comments.
Others please chime in!!!

OFIWG stands for OpenFabrics Interfaces (OFI) Working Group (WG), and the abstract to our Hoti23 paper starts by defining "OFI" as "a new family of application program interfaces that exposes communication services to middleware and applications", and "Libfabric" as "the first member of OFI".
The Introduction to that paper starts by further defining "OFI" as a framework focused on exporting communication services to applications".
The section of that paper entitled "Architectural Overview" starts by defining "the general architecture of the two main OFI components, the libfabric library and an OFI provider" (see Figure 1 in that paper).
Finally, the names of all the functions, structures, macros, etc. in libfabric start with the prefix "fi_" or "FI_" as appropriate.

my comments on our DS/DA slide deck:
We need similar short, crisp definitions right up front.
We should start with mentioning "OFI" and "libfabric"
up front, along with "kverbs", and then relating "kfabric"
and "kfi" to them all.  For instance, is "kfi" just "another"
interface to "OFI" designed for kernel apps, conceptually parallel to "libfabric" for user apps?

slide 1 is entitled: "kfi - Kernel Fabric Interface"
but the first "definition" is given in slide 4, which is entitled "kfabric, libfabric relationship"
and defines "kfabric" as "kernel modules for storage and remote data access" and "kfabric is not the kernel component of libfabric", which in turn is "a user-mode library for distributed and parallel computing".
In my notes from last week I wrote that we came to the consensus that "kfi" was (the 1st) implementation of "kfabric", which is the "architecture or concept" for potentially a whole set of implementations, much as libfabric is the 1st implementation of OFI.

Do I have this correct?
If so, perhaps slide 1 should use "kfabric", not "kfi"?
In any case, we should explicitly state that "kfi"
is the implementation of the "kfabric" architecture, and this should come before slide 5, because slide 5 introduces "Kverbs" without relating it to "libfabric"
and says "kfi is expected to call kverbs ..." without explaining anything about the relationship between "kfi"
and "kfabric".
The 3rd bullet on slide 5,  says "kfabric complements sockets ...".
Isn't this talking about the "kfabric" and "sockets" architectures?

However, slide 6 is back to "kfi objectives" -- shouldn't that be "kfabric objectives", since again it seems to be about concepts, not implementations.

Slide 7 talks about "positioning kfi in the Linux kernel", probably because "kfi" is an implementation.  But the "Rationale" bullet is all about "kfabric" -- shouldn't that bullet all be about "kfi"?  Or should the whole slide be about "kfabric" because this is really an architectural discussion?

Slide 8 is entitled "Storage protocols", but would be better entitled "Storage protocols and Sockets", since that is what it is all about (as an architecture).

Slide 9 is also entitled "Storage protocols", but would be better entitled "Storage protocols and kfabric", since that is what it is all about (as an architecture).

Slide 11 gives the "KFI Framework", but is this for the general "kfabric" architectures or the "kfi" implementation?

Slide 12 is specifically about "KFI", but it seems to be a "kfabric" architectural discussion.

Slides 13, and 15 seem to be about the "kfi" implementation.
I believe in slide 13 we should stress "Kernel consumer API"
and "Kernel provider API", both singular since the "kfi_*"
names shown are specific to the "kfi" implementation.

Slide 16 has "kfabric" as the root of a tree with "kfi"
as one of the nodes.  Presumably because future alternatives to the "kfi" implementation will still be part of the "kfabric" architecture.  It is not clear from this diagram where the "libfabric" providers fit in (maybe not necessary?)

ofiwg mailing list
ofiwg at lists.openfabrics.org

More information about the ofiwg mailing list