Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] calling sendi earlier in the PML
From: Eugene Loh (Eugene.Loh_at_[hidden])
Date: 2009-03-03 15:59:11

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.