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.
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
>> 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.
>> On Nov 5, 2007, at 8:01 AM, Terry Dontje wrote:
>>> Currently in order to do message tracing one either has to rely on
>>> 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
>>> 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
>>> pass in a request handle or communicator handle to get the
>>> data back.
>>> This is just a thought right now which why this email is not in an
>>> 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
>>> interfaces. If the responses seems positive I will follow this
>>> up with an RFC.
>>> devel mailing list
>> devel mailing list
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s