Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: convert send to ssend
From: George Bosilca (bosilca_at_[hidden])
Date: 2009-08-24 14:26:43

On Aug 24, 2009, at 13:25 , Jeff Squyres wrote:

> On Aug 24, 2009, at 11:35 AM, George Bosilca wrote:
>> As a side note, a very similar effect can be obtained by decreasing
>> the eager size of the BTLs to be equal to the size of the match
>> header, which is about 24 bytes.
> I disagree with this statement. ;-)
> We currently don't export the BTL or PML header size, so you can't
> possibly know what value to set the eager limit to. And even if we
> did, as the conversation between you, me, and Brian from the last
> Chicago Forum meeting proved, the exact definition of "eager_limit"
> is a fairly nebulous thing.

It's enough to ask somebody who knows. While I agree that we don't
have a simple definition of the eager_limit, for this particular topic
it's enough to set it as low as possible.

> My point is that this is a fairly trivial-to-implement feature. It
> can even be done in a way that doesn't impact performance at all
> (default to compile out).

It is more trivial than this: mpirun -np 2 --mca
btl_tcp_rndv_eager_limit 0 --mca btl_tcp_eager_limit 72 --bynode ./
NPmpi ?

> We all know that there are many MPI correctness tools that are
> available, but it can be difficult to get users to actually use
> them. If they can flip a switch a mpirun time to turn on some
> semantic checking, that's a Good Thing.

I know the approach "because we can". We develop an MPI library, and
we should keep it that way. Our main focus should not diverge to
provide features for a hand of users, features that will barely be
maintained and that might hit us back in the future. There are way to
many critical features that we need now, to focus on something as
trivial as transforming sends in ssends.

Anyway, we are a community based project and the vote of the community
will decide the fate of this RFC.