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.
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
Dresden also) if Open MPI would create a couple APIs that exoposed the
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
extending the PERUSE probes or creating actual functions that one would
pass in a request handle or communicator handle to get the appropriate
data back.
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
up with an RFC.
thanks,
--td
_______________________________________________
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
