[mpiwg-p2p] Next meeting: 27th October 2014 11am Central US

Fab Tillier ftillier at microsoft.com
Tue Nov 4 12:45:06 CST 2014


Hi Folks,

Sorry for not following this more closely, but here are my thoughts (in no particular order):
- Shouldn't the new send/recv functions use MPI_Count rather than int for the count parameter?
- It would be nice if there was a no-copy mode, where the channel's buffer is returned to the user, and later returned to the MPI library.  Rather than passing in a buffer in which to receive the data, the call would retrieve the address and length of received data.  You'd need a second call to mark that data range "consumed" so that it could be reused.  It's then up to the application to copy if appropriate, though it does change the semantics to byte stream (i.e. no datatypes) in this mode.
- Should channel creation provide a hint in terms of the buffer size that should be allocated internally?
- Having a way to "query" the internal buffer of the channel such that the application could use it directly, and avoid a copy on send, could be a nice feature.

Cheers,
-Fab

Daniel Holmes wrote on Mon, 27 Oct 2014 at 08:18:47

> Hi all,
> 
> The next point-to-point teleconference will be - today, in about 45
> minutes - on Monday 27th October 2014 at 11am Central US via webex.
> 
> Connection details are on the p2p wiki.
> 
> Agenda: 1) Streams - continued discussion of feedback from the Japan
> meeting. Last time (see notes for 27th November 2014), we discussed the
> first half dozen slides from the channels presentation. See
> https://svn.mpi-forum.org/trac/mpi-forum-
> web/attachment/wiki/PtpWikiPage/Streams/channel-p2pwg-mpiforum-
> sep2014.pptx We should discuss more of these slides, i.e. the proposed
> interface.
> 
> 2) AOB (= any other business).
> 
> Notes:
> a) Receive_reduce - on hold
> b) Arecv - on hold
> 
> Cheers,
> Dan.
>



More information about the mpiwg-p2p mailing list