MPI Forum Meetings logo

MPI Forum: mpi3-rma Mailing List Archives

all MPI Forum: mpi3-rma mailing list

Subject: Re: [mpi3-rma] Plans ?
From: Pavan Balaji (balaji_at_[hidden])
Date: 2008-01-27 20:08:44


Rich, Jarek,

The ordering should definitely not be enforced in all cases. As I
mentioned in the brief description below, the application should be able
to inform the MPI stack to flush out previous requests through a
"special tag". Consider an example where the sender wants to place some
data in the receiver buffers through RMA operations and inform it that
the data is written through a regular send operation -- this can be
achieved by tagging the last send with the special tag, instead of
having the receiver wait for the window to be closed before being able
to use the data received through RMA operations. This is similar to
fence, but on a process-pair basis, rather than on a window basis.

  -- Pavan

On 01/27/2008 06:50 PM, Nieplocha, Jarek wrote:
> Good point Rich.
>
> Enforcing ordering for all the cases say on networks with adaptive routing can be expensive and unnecessary.
>
> Jarek
>
> ________________________________
>
> From: mpi3-rma-bounces_at_[hidden] on behalf of Richard Graham
> Sent: Sun 1/27/2008 4:44 PM
> To: MPI 3 Remote Memory Operations
> Subject: Re: [mpi3-rma] Plans ?
>
>
> Can you elaborate on this ?
>
> What is the intent ?
>
> Do you want to have ordering be required, or optional ? Seems like there are times
> where you would like to have ordering guarantees, and others in which you want the
> network to blast things through as fast a possible, w/o concern for ordering.
>
> Rich
>
>
> On 1/27/08 12:26 AM, "Pavan Balaji" <balaji_at_[hidden]> wrote:
>
>
>
>
>
> I was planning to write a proposal on ordering and completion of
> requests. Specifically, to treat RMA operations as ordered with respect
> to how application writers perceive it. That is, if process A sends an
> RMA message to process B, and then sends a regular message to process B
> (with a special TAG, for instance), the MPI stack on process B should
> deliver both the RMA message as well as the regular message to the
> application. That is, it should not wait for the remote window to close
> before doing so.
>
> However, it'll be good to have a telecon to bounce off ideas and get
> initial comments before we go off and spend time writing more detailed
> proposals.
>
> Is a telecon being planned? I don't seem to have received any email
> about this.
>
> -- Pavan
>
> On 01/26/2008 10:43 PM, Rajeev Thakur wrote:
> > It would be good to know if anyone is planning to write a proposal on any
> > topic for MPI-3 RMA.
> >
> > Rajeev
> >
> >> -----Original Message-----
> >> From: mpi3-rma-bounces_at_[hidden]
> >> [mailto:mpi3-rma-bounces_at_[hidden]] On Behalf Of Richard Graham
> >> Sent: Wednesday, January 23, 2008 10:18 AM
> >> To: mpi3-rma_at_[hidden]
> >> Subject: [mpi3-rma] Plans ?
> >>
> >> What are the plans for this working group ? At the meeting
> >> last week there seemed to be quite a bit of interest in this
> >> topic, and it seemed like there could be at least 2 groups
> >> working on this. Seems like, if this is the case, it would
> >> be better to try and coordinate early on within the working
> >> group, rather than try and rationalize two or more well
> >> developed proposals.
> >> Any thoughts here ?
> >>
> >> Rich
> >>
> >> _______________________________________________
> >> mpi3-rma mailing list
> >> mpi3-rma_at_[hidden]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-rma
> >>
> >>
> >
> > _______________________________________________
> > mpi3-rma mailing list
> > mpi3-rma_at_[hidden]
> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-rma
> >
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-rma
>
>
>
>
>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi3-rma
>

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji