[Mpi-forum] MPI "Allocate receive" proposal

[Underwood, Keith D]

> As per the use case, at least ADLB and Charm++ will benefit from this.
> They don't know what message size will come in.  But I'm sure there are
> more.

But, do they know *approximately* the size of the message that is expected?  Because, if they do, then most of the advantage isn't there.  I struggle a little bit with the idea of well coded apps that have little enough idea about the size of the message that they need this. 

> My concern is not whether someone can use it, but rather with respect to
> how much the MPI implementation can do without the sender knowing if
> the receiver is going to receive the message using RECV or ARECV.  But
> maybe with Iarecv, it'll not be a problem.

I'm more concerned about calling malloc() in the library.  At the end of the day, even with the measly int-limited max message size, you will *have* to malloc in that path.

I am also wondering if there is a better way to do this by exposing the traditional rendezvous?  Sure, if you are under the rendezvous threshold, toss the eager receive buffer up.  If you are above the threshold, toss it up to the library and provide a way to do a "pull" of the rest of the data.  You could even go crazy and push an opaque handle out at the receiver to use in the pull.  Given the implementation implications of this concept, my bias would be to not hide reality from the user.  We should really only abstract the things for which the MPI library can do optimizations on the user's behalf.  If we exposed and efficient way for the user to do rendezvous themselves, that may be better.

Keith