I kind of remember that we had a discussion about this long ago, and
that we decided to have it this way for latency. Now looking at the
code it seems way to ugly to me. I think Brian have a point. MPIPobe
and MPI_Iprobe are MPI functions, and they are expected to make
progress all the time. So call opal_progress, then do the probe seems
like the smartest and simplest approach.
However, if you want to do this, then it's better if we do it in the
right way. What we have today in the PML OB1 or probe is horribly
expensive. Initialize a complete request, that will never be used for
anything than matching is an overkill. The only fields that you really
need are the flags and the matching information. How about, creating a
request, setting these flags and then call the matching directly ?
This way, we can create a special path or probes, and this will remove
some ifs from the critical path for receives ...
On Jun 18, 2008, at 3:57 PM, Brian W. Barrett wrote:
> On Wed, 18 Jun 2008, Terry Dontje wrote:
>> Jeff Squyres wrote:
>>> Perhaps we did that as a latency optimization...?
>>> George / Brian / Galen -- do you guys know/remember why this was
>>> On the surface, it looks like it would be ok to call progress and
>>> check again to see if it found the match. Can anyone think of a
>>> deeper reason not to?
>> If it is ok to check again, my next question is going to be how?
>> Because after looking at the code some more I found iprobe requests
>> are not actually queued. So can I just do another
>> MCA_PML_OB1_RECV_REQUEST_START on the init'd IPROBE_REQUEST after
>> the call opal_progress to force a search on the unexpected queue
>> or do I need to FINI the request and regenerate it again?
> I think you'd have to re-init the request at a minimum. In other
> words, just always call opal_progres at the top of iprobe and be
> done :).
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s