> 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. 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.) > 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 _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
