Re: [OMPI devel] accessors to context id and message id's

[George Bosilca]

On Nov 6, 2007, at 8:38 AM, Terry Dontje wrote:

George Bosilca wrote:

If I understand correctly your question, then we don't need any
extension. Each request has a unique ID (from PERUSE perspective).
However, if I remember well this is only half implemented in our
PERUSE layer (i.e. it works only for expected requests).

Looking at the peruse macros it looks to be that the unique ID is the
base_req address which I imagine rarely matches between processes.

  george.

That's a completely different topic. If what you need is a unique ID for each request between processes, in other words, a unique ID for each message, then here is the way to go. Use the same information as the MPI matching logic, i.e. (comm_id, remote, tag) to create an identifier for each message. It will not be unique as multiple messages can generate the same ID, but you can generate a unique ID per messages with easy tricks. The PERUSE standard requires that the ID is unique for each process, and for the lifetime of the request. It does not require that the ID be unique across processes. And this is why we're using the base_req as an ID.

This should be quite easy to fix, if someone invest few hours into it.

For the context id, a user can always use the c2f function to get the
fortran ID (which for Open MPI is the communicator ID).

Cool, I didn't realize that.

thanks,

--td

 Thanks,
   george.

On Nov 5, 2007, at 8:01 AM, Terry Dontje wrote:

Currently in order to do message tracing one either has to rely on some error prone postprocessing of data or replicating some MPI internals up

in the PMPI layer.  It would help Sun's tools group (and I believe U

following:

1. PML Message ids used for a request
2. Context id for a specific communicator

I could see a couple ways of providing this information.  Either by

data back.


up with an RFC.

thanks,

--td
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Dresden also) if Open MPI would create a couple APIs that exoposed the extending the PERUSE probes or creating actual functions that one would pass in a request handle or communicator handle to get the appropriate This is just a thought right now which why this email is not in an RFC format. I wanted to get a feel from the community as to the interest in such APIs and if anyone may have specific issues with us providing such interfaces. If the responses seems positive I will follow this message

------------------------------------------------------------------------

_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

smime.p7s
Description: S/MIME cryptographic signature