Re: [ofiwg] Next steps on NVM PM Remote Access for HA

[Hefty, Sean]

FWIW, I read through this document:

> https://www.snia.org/sites/default/files/technical_work/final/NVM_PM_R
> emote_Access_for_High_Availability_v1.0.pdf

made several notes, mostly around trying to identify API requirements, and then 
promptly forgot what I was thinking when I made the note.  :)  I tried to 
enumerate any implied requirement, and many are already handled by OFI.


General comments:
-
3.4. An example where the NIC can access the NVM directly would be useful, 
including access to disaggregated memory.  I.e. avoid CPU caches.  It might be 
useful to show accelerators with access to NVM as part of the consideration.

3.5. Does this model exist?  This section seems out of place and doesn't appear 
to be addressed.

4.2. Fred and Barney analogy is odd and unnecessary.  Mention of MS VSS is also 
odd.  It would be 
better to describe the abstract concept rather than a specific product.  I'm 
struggling to extract specific requirements from this section.


API requirements:
-
 4.1  copy data from local memory/nvm to remote memory/nvm
 4.3  support out of order completions
 4.4  need explicit definition of data placement order
 4.5  QoS guarantee for bandwidth and/or latency
 6.2  register mmapped persistent memory
  possible register device/uncached pmem
 6.3  write with durability semantics
 6.4  data/completion ordering semantics defined -- prior to flushing data
  remote read of pmem
 6.5  support different CPU architectures
 7.2  need MR keys for protection
  limit allowed access to regions
*7.3  maybe support encryption from fabric services (IPSec?)
 8report errors to app
*8.2  maybe support replication capability (from source and/or target NICs)
*8.3  data corruption detection

I marked the areas that I see as gaps with *.  These are encryption/IPSec, data 
replication, and data corruption detection.  Note that I'm not suggestion that 
OFI necessarily address these gaps, but might be areas for further discussion.

- Sean
___
ofiwg mailing list
ofiwg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ofiwg

Re: [ofiwg] Next steps on NVM PM Remote Access for HA

[Paul Grun]

A reminder to OFIWG - Please review the existing SNIA white paper, "NVM PM 
Remote Access for High Availability v1.0.  A link to the document is given in 
Doug's email below.
I would like to use part of next Tuesday's OFIWG meeting to collect any 
comments or input.
Please don't wait until next week though...your comments via email will be very 
helpful as soon as possible.

Regards,
-Paul

From: ofiwg [mailto:ofiwg-boun...@lists.openfabrics.org] On Behalf Of Voigt, 
Doug
Sent: Monday, April 23, 2018 10:48 AM
To: ofa_remot...@lists.openfabrics.org; nvmp...@snia.org; ofiwg 
(ofiwg@lists.openfabrics.org) 
Subject: [ofiwg] Next steps on NVM PM Remote Access for HA

With the approval of the OFA-SNIA Alliance on Remote PM (attached  ), OFA and 
SNIA have agreed to collaborate on 2 deliverables:
*The next revision of the "NVM PM Remote Access for HA" white paper
*A new remote PM use case enumeration

As the editor first version of the NVM PM Remote Access for HA white paper, I 
have volunteered to begin defining the next version.  I think the best way to 
do that would be to review the current public version of the document in ofiwg. 
 I would be happy to briefly introduce that document in an upcoming ofiwg 
meeting, however the review itself should be driven by participants interested 
in the work of the alliance reading and commenting on the document at
https://www.snia.org/sites/default/files/technical_work/final/NVM_PM_Remote_Access_for_High_Availability_v1.0.pdf

Comments that arise from that review can then be merged with a list of 
modifications already suggested by prior reviewers.  The list so far includes 
the following:
Section 3.3 - Add OmniPath, Gen-Z, Open CAPI and CCIX to the description of 
Disaggregated Persistent Memory in the remote access taxonomy
Section 4 - Add sub-sections on integrity checking and pipelined sequences of 
RDMA operations for transactions.
New section - introduce the relationship between visibility and durability.
Section 5 - add asynchronous flush, enhance RDMA stack model, revisit figure
Section 6 - add discussion of flush scope, flush barrier ordering and more 
detail on pipelined sequences of RDMA for transactions
Section 6 - update all figures
Section 8 - describe limited role of network infrastructure in media error 
handling, reference integrity check, address "delivered but not durable" 
scenario.
Section 9 - Revisit requirements summary

Paul Grun and I will coordinate the scheduling of this review in ofiwg.

Work on the use case enumeration deliverable will proceed in parallel with this 
review.

Thank You,
Doug Voigt,
SNIA NVMP TWG co-chair


___
ofiwg mailing list
ofiwg@lists.openfabrics.org
http://lists.openfabrics.org/mailman/listinfo/ofiwg