[ofiwg] DS/DA discussion
atchleyes at ornl.gov
Tue Oct 6 11:30:54 PDT 2015
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
> 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. ;-)
More information about the ofiwg