notes 2017 03 27

27th March 2017 Meeting Notes

Attendees

Dan Holmes
Jim Dinan
Ken Raffenetti

Agenda

1. the INFO GET/SET problem (issue #63 on git)

   Consensus that this issue is ready to vote on at next face-to-face meeting, unless Pavan discovers compelling counter use-cases.

2. the Allocating Receive & Freeing Send extension (#32 on git)

   Who first owns (i.e. allocates) the memory, MPI or the user? If the user, then we need something like MPI_BUFFER_ATTACH but with a communicator argument to permit isolation of resources per comm handle. If MPI, then we need an INFO key or API function to instruct MPI to allocate buffer space for a particular communicator. MPI allocation permits usage of special memory not normally accessible by the user.

   How does the original owner retrieve ownership to enable freeing the memory? Possible to permit/require MPI_Fsend or MPI_Arecv to/from MPI_COMM_NULL. The user-owns new MPI_COMM_BUFFER_ATTACH would have a matching MPI_COMM_BUFFER_DETACH function. The user have to own the memory at the point of calling it.

   What about non-blocking/persistent versions? Non-blocking Fsend doesn't make sense: completion means user can re-use buffer but user cannot re-use a freed/unowned buffer! Implies persistence doesn't make sense either. Unless the functions take void** buf and then completion means the user can overwrite their pointer because MPI has copied/used it. Same argument for non-blocking/persistent Arecv. Do we want to expose users to void** here, in the API or in the semantic usage of void* buf?

   Which combinations of send modes work/give benefit? Need sequence diagrams for different scenarios (cross-product of large/small message sizes, all four modes, etc). Are we really advocating adding a freeing version of all four send modes? With non-blocking and persistent (and receive options) that would double point-to-point combinations from 36 to 72!

DONM: Mon 10th April 2017