Jeff Squyres wrote:
On Mar 3, 2009, at 4:04 PM, Eugene Loh wrote:
How about an MCA parameter to switch between this mechanism (early
sendi) and the original behavior (late sendi)?
This is the usual way that we resolve "I want to do X / I want to
do Y" disputes. :-)
I see the smiley face, but am unsure how much of the message to
apply it to.
It applied to that sentence only -- the proposal was genuine.
Assuming the MCA proposal is genuine (easy for implementor
consensus? or easy for the user? gee, lemme see, that's a tough
choice...), I'll note that it's easy enough to do. I've implemented
the early-sendi-check by adding a function to ob1 to do the right
thing. So, I can call that function as soon as one enters the PML
send. The "late sendi" call is at a different call site. So, one
call site for "early sendi" and another for "late sendi". Easy to
turn on/off. We're not talking about many small codes changes
pervading the source base.
True, but Brian hated it. :-)
I guess, but *I* didn't hate it. I thought you were trying to be
funny. Brian just needs to get a sense of humor.
How about Brian's proposal?
Um, how to put it politely? With your proposal, I didn't like the idea
of exposing more MCA knobs. With his proposal, I didn't like the idea
of exposing more MCA knobs whose meaning is hard to decipher.
Let me try another thought here. Why do we have BTL sendi functions at
all? I'll make an assertion and would appreciate feedback: a BTL sendi
function contributes nothing to optimizing send latency. To optimize
send latency in the "immediate" case, we need *ONLY* PML work.
I'm churning a lot and not making much progress, but I'll try chewing on
that idea (unless someone points out it's utterly ridiculous). I'll
look into having PML ignore sendi functions altogether and just make the
"send-immediate" path work fast with normal send functions. If that
works, then we can get rid of sendi functions and hopefully have a
solution that makes sense for everyone.
