Ok, I'll see if I can figure out the below. Though is this really
something that can be used in both MPI_Iprobe and MPI_Probe? One other
question, is the use of opal_progress in MPI_Iprobe the right thing to
do? Is there something a little lighter weight (bml_progress maybe)?
--td
George Bosilca wrote:
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 ...
george.
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 done?
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
:).
Brian
_______________________________________________
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
