[Mpi3-ft] FT Working Group Teleconf (today)

[Greg Bronevetsky]

At 07:13 AM 3/24/2010, Richard Treumann wrote:

>I just took a look at the piggy back proposal. I do not see a 
>fundamental problem but there are a couple points worth a mention
>
>1) Mandating extra fields in a status object breaks binary 
>compatibility. An MPI library that assume it is filling in new form 
>status when the application was compiled with old form status will 
>trash some other part of memory. When a status was determined to be 
>a user allocated structure in MPI 1.0, the ability to change it was forfeited.
I don't believe that binary compatibility is a goal for MPI 3 and in 
the survey users rated it quite low on their priority list.

>2) Expecting libmpi to recognize that the piggyback sent was bigger 
>than the piggyback expected and truncate the piggyback while 
>delivering an intact user message is not going to be practical. The 
>MPI standard should treat this exactly the way it treats any 
>send/recv in which type signatures do not match. I.E. if total bytes 
>sent is <= total expected, the outcome is undefined and if total 
>bytes sent is > total expected it is an error and the resulting 
>buffer content is undefined. The standard only obliges libmpi to 
>refrain from trashing memory outside the footprint of the typemap.
>
>IBM uses an approach that distributes inbound packets (which may 
>arrive out of order) directly into the receive type map. If the 
>bytes coming in > expected we discard all packets and if <=, we put 
>the bytes wherever the recv side typemap says and have no way of 
>knowing the send type signature and recv type signature are 
>inconsistent. Adding metadata to validate send type signature 
>against recv type signature would be too expensive

That's fair. We shouldn't make piggybacking semantics more stringent 
than regular application data semantics.

Greg Bronevetsky
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky at llnl.gov
http://greg.bronevetsky.com