RMA WG 01 31 2019

Agenda

Discussion on PR#214

(Min) For “some/any” API, status does not need to be an INOUT parameter, rather should just be IN parameter. Since the API will not be called in a loop, the status updates will not be needed. Problems are redundant information, and overhead. The user can always update the status in the user code.
(Jim) The wait-any example in the PR shows a use case where wait-any API is enclosed in a loop. Status with an index check can be added in the user code if we don’t want to keep status as an INOUT argument. With the current version, the user does not have to write this part.
(Nick) Not exactly redundant (status info). Both variants have its own benefits.
(Jim) Cache miss would be less for the current version as SHMEM library would load the status early so, it will be hit next time.
(Min) The use case is invoke the API once. The current version should work, but the changes in the status array does not help.
(Dave) From usability perspective, prefer the current API. Need feedback whether there is a strong reason for not keeping the current API.
(Nick) Min’s suggestion would be useful to keep when the intention to keep the status array as constant for future use.

Discussion of Put-Signal and Memory Model proposals

(Jim) Presenting the slides on memory model discussion (attached in the email sent prior to meeting)
(Jim) put, putmem, processor store would not be compatible for p2p sync.
(Pasha) Interconnect may not issue a shmem_p with a single PCIe write. Multiple layers need to be considered: interconnect, pcie, bus, etc. NIC may issue out-of-order PCIe writes for performance reasons.
(Jim) NIC would use a PCIe atomic to ensure no partial updates. Performance penalty for PCIe swap w.r.t. PCIe write.
(Manju) There will be future support of using either PCIe Atomics or NIC atomics. NIC atomics should also be a choice to consider (feedback on table at slide#5)
Will pick up from slide #5 in the next meeting. Creating a google doc would be helpful.