RMA WG 11 29 2018 - openshmem-org/specification GitHub Wiki

Agenda

  1. Discussion of interaction between put-with-signal and wait operations

Attendees

  • David Ozog, Wasi Rahman, Jim Dinan (Intel)
  • Anshuman Goswami, Akhil Langer (Nvidia)
  • Min Si (ANL)
  • Naveen Ravichandrasekaran (Cray)
  • Manjunath Gorentla (Mellanox)

Open Action Items

  • None

Action Items

Notes

  • (Naveen) Non-blocking AMO will be queued for reading.
  • (Jim) SOS implementation for non-blocking AMO. Unit tests added.
  • (Naveen) User option for Shmem_wait with put_signal added
  • (Anshuman) 3 options: shmem_p and wait_until should work. Shmem_p can be used for sync. Shmem_p cannot be used for sync.
  • (Anshuman) Shmem_wait cannot react to partial updates.
  • (Naveen) The current implementation is limited to 2 PEs
  • (Jim) For symmetric data segment, it should not be limited to 2 PEs. If atomic for signal is used, there should be correct well-defined behavior.
  • (Naveen) Depending on the hardware, signal update can be anything. We should not explicitly say the operation type for signal update.
  • (Jim) In such case, quiet or fence should guarantee completion of the signal operation. If shmem_p is not made compatible with wait, then the semantics are well defined. Keeping put_signal operation as point-to-point sync is the better choice. Texts need to be added to make sure users do not use this in producer-consumer scenario.
  • (Naveen) The signal update should be atomic. Implementation-wise, it can be globally visible or only to the target.
  • (Jim) It should be similar to scalar put semantics
  • (Manju) From x86 perspective, can there be a single copy atomicity guarantee?
  • (Jim) A pseudocode example to present the case where single-copy atomicity fails on x86?
  • (Naveen) Would wait to hear input from Pasha
  • (Jim) One way is to look at the memory after a NIC event. Reference to a PCIe Spec would be helpful