On Oct 6, 2015, at 1:30 PM, Hefty, Sean <[email protected]> wrote:
>> Of the possible devices, what do they need that OFI does not yet have? >> Flags or operations to indicate that a memory should persisted (I think >> Intel gave an example of a new instruction to move data into a >> “persistence domain”)? Does it lack a “commit” or “sync” operation to make >> the remote device perform a storage-specific operation? Something else? > > My main concern is that interface changes be driven by the application needs > and not the hardware implementation (or even application implementation), > especially when selected out of convenience. > > So far, we've discussed adding: > > - completion model > - 'commit or sync or flush' operation > - 'commit or sync or flush' flags > - memory registration flag > > Maybe the best answers are provider specific options or prototype interfaces, > with software simulation. Hi Sean, Thanks for the feedback. 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. 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? I agree that provider-specific solutions might make sense until we have a handle on the use cases. Scott _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
