[ofiwg] DS/DA discussion

[Atchley, Scott]

On Oct 6, 2015, at 1:30 PM, Hefty, Sean <sean.hefty at intel.com> 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