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?
On Jun 17, 2008
I'm sure it was a latency optimization, just like the old test behavior.
Personally, I'd call opal_progress blindly, then walk through the queue.
Doing the walk the queue, call opal_progress, walk the queue thing seems
like too much work for iprobe. Test, sure. iProbe... eh.
Brian
On Wed,
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?
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. C
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
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
No, please call the opal_progress. Otherwise, you will create
different behavior based on the available networks, basically the
networks that register a socket and those who don't. It might not be a
big deal today (except if the user call MPI_Iprobe to progress
communications), as TCP is th
Hi again... I was on a break from Xensocket stuff This time some general
questions...
Forgive me for the question its a quick one and related to some of my
development work on Xen, I will explain the rationale after the question. What
if I have multiple Ethernet cards (say 5) on two of
Ok however, I've seen a 40-150us hit by calling opal_progress. Which is
why I was hoping for something lighter weight.
--td
George Bosilca wrote:
No, please call the opal_progress. Otherwise, you will create
different behavior based on the available networks, basically the
networks that regis
Hi again... I was on a break from Xensocket stuff This time some general
questions...
Forgive
me for the question its a quick one and related to some of my
development work on Xen, I will explain the rationale after the
question. What if I have multiple Ethernet cards (say 5) on two o
10 matches
Mail list logo
