[Mpi-forum] MPI "Allocate receive" proposal

[Rolf Rabenseifner]

> Note that the type matching rules for send-receive say that MPI_BYTE
> matches only MPI_BYTE, not MPI_INT/FLOAT, or other type (pg 33-34). So
> this function would have to take a datatype argument, otherwise it
> would match only sends of bytes.

See 2) in my previous email. I would propose to add an etype.

- Rolf

----- Original Message -----
> From: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Sent: Monday, August 26, 2013 6:17:05 PM
> Subject: Re: [Mpi-forum] MPI "Allocate receive" proposal
> I've three other question/comments.
> 
> 1) Your last slide 7 says
> 
> - ARECV scenario: unexpected
> ...
> T=2: buffers unexpected message,
> puts on unexpected list
> 
> At this time, it is absolutely unknown, whether a
> following MPI_(I)recv or MPI_(I)arecv will be called.
> 
> The message may be sent with MPI_Send / Bsend / Ssend
> (not Rsend because here scenario is "unexpected).
> 
> Please, can you clarify, what may be the expected inner
> behavior for all three forms of sending and both forms
> of receiving.
> 
> 2) I do not understand the datatype concept.
> There should be something like an etype
> and the MPI_Arecv(...etype...) receives a multiple
> etypes and a multiple of etypes must match
> "count, datatype" in the MPI_Send call.
> one may use the same restrictions on this etype
> that exist for the MPI-I/O etype.
> 
> 3) Small notice: you may use BASEPTR instead of buffer.
> Your MPI_Status_get_buffer(status, &buffer)
> Returns a baseptr in the same way as MPI_ALLOC_MEM.
> Your MPI_Free_mem(buffer) frees the "base".
> Please note that this baseptr/base interface is asymetric.
> 
> Best regards
> Rolf


----- Original Message -----
> From: "Rajeev Thakur" <thakur at mcs.anl.gov>
> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Sent: Tuesday, August 27, 2013 5:20:33 AM
> Subject: Re: [Mpi-forum] MPI "Allocate receive" proposal
>
> Note that the type matching rules for send-receive say that MPI_BYTE
> matches only MPI_BYTE, not MPI_INT/FLOAT, or other type (pg 33-34). So
> this function would have to take a datatype argument, otherwise it
> would match only sends of bytes.
> 
> Rajeev
> 
> 
> On Aug 26, 2013, at 10:10 AM, Jeff Squyres (jsquyres) wrote:
> 
> > Dave Goodell and I have a proposal that we've socialized a bit
> > around with other Forum members, and would now like larger Forum
> > feedback. I'll be presenting the attached slides on the concept of
> > an "allocate receive" in Madrid (3:30-4pm on Thursday).
> >
> > There's no text or ticket yet; this is an idea that we want to get
> > feedback on before working up a full proposal.
> >
> > --
> > Jeff Squyres
> > jsquyres at cisco.com
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/
> > <arecv.pptx>_______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)