On Oct 6, 2015, at 2:24 PM, Hefty, Sean <[email protected]> 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 _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
