MPI_Parrived_any API as an addition for Partititioned Communication

[tonyskjellum]

Problem

The ability to take the next available partition is not supported in the current MPI-4.0 API.

Proposal

The API:

MPI_Parrived_any(MPI_Request prequest, int *partition, int *flag); /* C interface */

The flag will return true if a partition was available, or else false. If true, then the variable partition will be filled with the partition delivered (based on receive-side partitioning of course). This procedure is local.

The parameter request must be an active receive-side partitioned point-to-point request, or else the call is erroneous. (Extensions for partitioned collective communication will be addressed later.)

Multi-Parrived form(s) (named can change at will):

MPI_Parrived_many(MPI_Request prequest[], int nrequests, int *pairs_of_ready_partitions, int *flags, int *nready);

The goal is to allow, for multiple partitioned receives, to test for one or more ready partitions. This yields a relatively complex interface as presently written, yet is closely related to MPI_Test_any for normal requests. An array of active prequests is posed with a length (nrequests); the pair_of_ready_partitions is a set of indexes into the prequest array and partition #. nready specifies the total length of the pairs_of_ready_partitions and flags list. Flags are set true if a partition is ready, otherwise left as is [check: we have to be compliant with the other forms of test.] Cross-cutting of multiple receives is essential to cope with the expected patterns of usage (e.g., 26 neighbors in a 3D halo code).

Changes to the Text

Appropriate text will be added.

Impact on Implementations

This API will have to be added.

Impact on Users

Users will be able to write code that is reactive to data as it arrives per partition, rather than in some receive-requested sequence.

References and Pull Requests

(https://github.com/mpi-forum/mpi-standard/pull/718)

[tonyskjellum]

@regrant --- will you help me finalize the variety of APIs and the proposal here? I think we need a cross-cutting MPI_Parrived_any for multiple channels, not just one.

Does there need to be a way to specify completion of multiple channels' partitions or multiple partitions in one call too, as a secondary discussion---not clear.

[regrant]

MPI_Parrived_any_any? maybe, but I wouldn't want to gate this off of that addition, since you could always use this over multi-channels to make it work

[tonyskjellum]

MPI_Parrived_any_any? maybe, but I wouldn't want to gate this off of that addition, since you could always use this over multi-channels to make it work

I added something to write up above just now, please critique.

[regrant]

Thoughts: in order to match up with testany and test some, maybe we should make the second call MPI_Parrived_some instead of many? Other than that, I see this as pretty straightforward and good to shop around.

[EmmanuelBRELLE]

What about providing instead an array of MPI_request as extra argument of partitionned communication calls (a MPI_Request for each partition), to fallback on standard MPI_[Test/Wait]any calls?

This would solve the Parrived_any_any issue (MPI_Waitany would get an array filled with partition requests from many channels) in addition to prevent from MPI specification duplications.

MPI_Precv_init would become
int MPI_Precv_init(void *buf, int partitions, MPI_Count count, MPI_Datatype datatype, MPI_Request partition_requests[], int source, int tag, MPI_Comm comm, MPI_Info info, MPI_Request *request)
where partition_requests would be of size partitions

[tonyskjellum]

We should revive this discussion for MPI-4.2 if possible, even though listed for MPI-5.

This is super useful for real applications. It enables the receive-side to process data as it comes in reactively, and supports the idea of out-of-order delivery from the sender (early-bird) given by the idea that the partitions are produced with load-imbalance potentially, but certainly out of order potentially.