[ofiwg] for tomorrow's DS/DA telecon

[Robert D. Russell]

Paul:

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!!!

Background:
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?)

thanks,
Bob