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: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?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?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
smime.p7s
Description: S/MIME cryptographic signature
