[ofiwg] DS/DA discussion

[Atchley, Scott]

On Oct 6, 2015, at 2:24 PM, Hefty, Sean <sean.hefty at intel.com> wrote:

>> The original interface assumes process-to-process communication. I am
>> simply wondering if that was too narrow for the storage aspect. Can the
>> current interface handle completely passive resources? There is no need to
>> “commit” memory in the process-to-process model, but the storage model
>> might.
> 
> I somewhat disagree here.  As you mentioned, RMA and atomics interfaces do not assume process-to-process communication.

We agree, which is why I said that they are appropriate for storage. Message queues and tag matching are not.

> I'm also not sure about the definition of completely passive.  A CM protocol requires some sort of message exchange, and reliability requires ACKs.  Libfabric does assume network communication, so probably isn't appropriate for local storage.  (I'm a fan of local storage being accessed using mmap.)

On the call, I mentioned that CM requires assistance. That assistance could come from the kernel, a userspace daemon, or the NIC/HCA/HFI.


>> Storage and/or persistent devices _may_ need something that process-to-
>> process model does not. I am trying to get people to think about the
>> semantics. Is the interface expressive enough?
> 
> As defined, my guess is no.  But based on my current understanding, the framework seems sufficient to go in one of several possible directions.
> 
> Maybe it makes sense to define ideal interfaces for storage, ignoring all other interfaces in the process.  Then see if the resulting API maps well with libfabric/interface-X, rather than working backwards.  (And maybe that's what the DS/DA WG is doing.)
> 
> - Sean

I think that we are stuck and this is my poor attempt to add some grease. ;-)

Scott