This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
We spent more time over emails on this thread than the time required
to write the patch. As apparently I'm the only one concerned about
what we have in our code base or the only one that do not perceive the
usefulness of such a feature, I belong to an ignorable minority.
As long as you don't make it compile by default, please ignore my
On Aug 24, 2009, at 15:30 , Jeff Squyres wrote:
> On Aug 24, 2009, at 2:26 PM, George Bosilca wrote:
>> > 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 ?
> You would have a user do that rather than
> mpirun --mca mpi_force_ssend 1 -np 2 --bynode ./NPmpi
> I'm an OMPI implementor and I'll never remember that the TCP BTL
> requires *2* eager limits, much less what their values are. :-)
My version is for free, it doesn't require _any_ modification in the
source code and no long term maintenance. In fact, what I'm trying to
say it's that we already have such a feature, except it doesn't have a
cool name (mpi_force_ssend) and it is slightly PML dependent.