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.