[ofiwg] KFI / libfabric discussion from last Tuesday

[Dave Goodell (dgoodell)]

[I thought I sent this out last week, but it sat in my draft folder for some reason.  Apologies for the delay]

Paul asked me to summarize the discussion that we had on Tuesday that spanned parts of both the DS/DA call and the libfabric call.  I unfortunately had to miss much of the 2nd call, so this is my (probably flawed) understanding of the conclusions that were reached.

At the DS/DA call I raised the question of whether KFI intended to cover any user space access mechanisms, esp. along the lines of replacing the existing Linux uverbs mechanism.  For clarity here, uverbs is the mechanism that allows user space processes to issue commands to the kernel to request various control path operations like opening devices or creating QPs.  It has a number of known deficiencies for non-IB hardware, and thus addressing those issues could plausibly fall under OFIWG's vendor-neutral, hardware-neutral focus.  The DS/DA group seemed to feel that this was outside the scope of their storage-focused work and would furthermore hurt the odds of eventually upstreaming the KFI code.

The libfabric call apparently discussed this for quite a while, and came to a few conclusions:

1. The core framework bits of libfabric do not need/want any kernel support (cf. libibverbs).  All kernel-interaction is handled by the providers.

2. The existing linux-rdma@/uverbs community frequently has trouble getting everyone to agree on how common functionality should be designed/implemented across disparate hardware devices/interfaces.  This leads to everyone's progress slowing down.

3. The libfabric group should stay out of this space at this point.

-Dave