2011/11/18 George Bosilca <bosi...@eecs.utk.edu> > > On Nov 18, 2011, at 11:50 , Hugo Daniel Meyer wrote: > > > 2011/11/18 George Bosilca <bosi...@eecs.utk.edu> > >> >> On Nov 18, 2011, at 11:14 , Hugo Daniel Meyer wrote: >> >> 2011/11/18 George Bosilca <bosi...@eecs.utk.edu> >> >>> >>> On Nov 18, 2011, at 07:29 , Hugo Daniel Meyer wrote: >>> >>> Hello again. >>> >>> I was doing some trace into de PML_OB1 files. I start to follow a >>> MPI_Ssend() trying to find where a message is stored (in the sender) if it >>> is not send until the receiver post the recv, but i didn't find that place. >>> >>> >>> Right, you can't find this as the message is not stored on the sender. >>> The pointer to the send request is sent encapsulated in the matching >>> header, and the receiver will provide it back once the message has been >>> matched (this means the data is now ready to flow). >>> >> >> So, what you're saying is that the sender only sends the header, so when >> the receiver post the recv will send again the header so the sender starts >> with the data sent? am i getting it right? If this is ok, the data stays >> in the sender, but where it is stored? >> >> >> If we consider rendez-vous messages the data is remains in the sender >> buffer (aka the buffer provided by the upper level to the MPI_Send >> function). >> > > Yes, so i will only need to save the headears of the messages (where the > status is incomplete), and then maybe just call again the upper level > MP_Send. A question here, the headers are not marked as pending (at least i > think so), so, my only approach might be to create a list of pending > headers and store there the pointer to the send, then try to identify its > corresponding upper level MPI_Send and retries it in case of failure, is > this a correct approach? > > > Look in the mca/vprotocol/base to see how we deal with the send requests > in our message logging protocol. We hijack the send request list, and > replace them with our own, allowing us to chain all active requests. This > make the tracking of chive requests very simple, and minimize the impact on > the overall code. > > george. > > Ok George. I will take a look there and then let you know how it goes.
Thanks. Hugo > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >