users should be able to query a request type

[jeffhammond]

Problem

We have a lot of different request types now: P2P, COLL, RMA, persistent P2P, persistent COLL, IO, maybe more.

As far as I know, all of the implementations internally know the type of every request internally but users cannot get this in a portable way.

It would be useful to me as a middleware developer to know the type of requests.

For example, status objects associated with RMA requests have undefined fields except for MPI_ERROR, and I'd like to know that I can ignore the undefined fields when doing a status conversion in Mukautuva.

For example, I would like to know if request objects are persistent, since I may need to handle those differently in some places.

Proposal

The kinds of requests will be enumerated as predefined integer constants like e.g. COMBINER kinds.

Option 1 requires an ABI break. Option 2 does not.

Option 1

Add a private field to the status object that contains the request type. Implementations decide what to store and users get the request type from MPI_Get_request_kind.

Option 2

The request objects themselves are queried via MPI_Get_request_kind.

Changes to the Text

This is the C API. The LIS is obvious enough.

Option 1

int MPI_Get_request_kind(const MPI_Status *status, int * request_kind)

Option 2

int MPI_Get_request_kind(const MPI_Request request, int * request_kind)

Kind enumeration

We can either be very explicit about request kinds, or put them in classes:

MPI_REQUEST_KIND_ISEND
MPI_REQUEST_KIND_IRECV
...
MPI_REQUEST_KIND_IALLTOALLW
...
MPI_REQUEST_KIND_RGET
...

MPI_REQUEST_KIND_P2P
MPI_REQUEST_KIND_COLL
...

I expect implementers will favor the latter because it is what they do internally.

Impact on Implementations

Option 1 is an ABI break and implementers will hate it.

Option 2 should be a trivial feature around the existing request kinds implementations use today.

Impact on Users

This will make it easier to introspect MPI in middleware, and make it possible for optimizations or defensive programming that is currently impossible to implement in a portable way.

References and Pull Requests

[devreal]

FWIW, the current status object in OMPI has a 4B field that essentially represents a boolean value, so we have 31 bits to encode the request type without breaking the ABI. I guess 8 bits would be sufficient to encode all possible request types. Not sure about MPICH.

Right now I have no opinion on whether request or status is the better place to store this information. I guess there are good use-cases either way.

[jeffhammond]

I doubt MPICH can spare the bits, unless they decide to make assumptions about the max message size being 48 bits or something like that, which would only provide 15 bits (1 bit is already for cancelled), so I am inclined to pursue Option 2.

[jeffhammond]

The reason Option 1 is better is that it provides a way to know the type of request that was completed, e.g. in a call to MPI_Waitany, whereas with Option 2 one has to query all the requests before the call, and then look up the request type after it. I'm not sure this sort of usage is compelling enough to create ABI problems.