Brian W. Barrett wrote:
On Tue, 3 Mar 2009, Eugene Loh wrote:
First, this behavior is basically what I was proposing and what
George didn't feel comfortable with. It is arguably no compromise at
all. (Uggh, why must I be so honest?) For eager messages, it favors
BTLs with sendi functions, which could lead to those BTLs becoming
overloaded. I think favoring BTLs with sendi for short messages is
good. George thinks that load balancing BTLs is good.
I have two thoughts on the issue:
I'll see your two thoughts and raise you... Oh wait. Maybe I'll win
more consensus if I were less shrill/insistent! :^)
1) How often are a btl with a sendi and a btl without a sendi going to
be used together? Keep in mind, this is two BTLs with the same
priority and connectivity to the same peer. My thought is that given
the very few heterogeneous networked machines (yes, I know UTK has
one, but we're talking percentages), optimizing for that case at the
cost of the much more common case is a poor choice.
Today, the only sendi code I see is:
*) mx (could potentially coexist with another BTL)
*) sm (was turned off, but I turned it back on... anyhow sm never
coexists with another BTL)
*) portals (turned off, and presumably unlikely to coexist with another BTL)
2) It seems like a much better idea would be to add sendi calls to all
btls that are likely to be used at the same priority. This seems like
good long-term form anyway, so why not optimize the PML for the long
term rather than the short term and assume all BTLs will have a sendi
function?
I wouldn't assume all BTLs will have a sendi function, but only that
low-latency BTLs would. But, maybe that's what you meant.
