I don't understand how your proposal is any different than what we have
today. I quote "If [locality flag is set], then we could keep a hard coded
test so 127.x.y.z address (and IPv6 equivalent) are never used (even if
included or not excluded) for inter node communication". We already have a
hardcoded test to prevent 127.x.y.z addresses from being used. In fact we
have 2 tests, one because this address range is part of our default
if_exclude, and then a second test (that only does something useful in case
you manually added lo* to if_include) deep inside the IP matching logic.
On Wed, Sep 21, 2016 at 12:36 PM, Gilles Gouaillardet <
> i got that, and i consider my suggestion as an improvement to your
> if i want to exclude ib0, i might want to
> mpirun --mca btl_tcp_if_exclude ib0 ...
> to me, this is an honest mistake, but with your proposal, i would be
> screwed when
> running on more than one node because i should have
> mpirun --mca btl_tcp_if_exclude ib0,lo ...
> and if this parameter is set by the admin in the system-wide config,
> then this configuration must be adapted by the admin, and that could
> generate some confusion.
> my suggestion simply adds a "safety net" to your proposal
> for the sake of completion, i do not really care whether there should
> be a safety net or not if localhost is explicitly included via the the
> btl_tcp_if_include MCA parameter
> a different and safe/friendly proposal is to add a new
> btl_tcp_if_exclude_localhost MCA param, which is true by default, so
> you would simply force it to false if you want to MPI_Comm_spawn or
> use the tcp btl on your disconnected laptop.
> as a side note, this reminds me that the openib/btl is used by default
> for intra node communication between two tasks from different jobs (sm
> nor vader cannot be used yet, and btl/openib has a higher exclusivity
> than btl/tcp). my first impression is that i am not so comfortable
> with that, and we could add yet an other MCA parameter so btl/openib
> disqualifies itself for intra node communications.
> On Thu, Sep 22, 2016 at 12:56 AM, George Bosilca <bosi...@icl.utk.edu>
> > My proposal is not about adding new ways of deciding what is local and
> > not. I proposed to use the corresponding MCA parameters to allow the
> user to
> > decide. More specifically, I want to be able to change the exclude and
> > include MCA to enable TCP over local addresses.
> > George
> > On Sep 21, 2016 4:32 PM, "Gilles Gouaillardet"
> > <gilles.gouaillar...@gmail.com> wrote:
> >> George,
> >> Is proc locality already set at that time ?
> >> If yes, then we could keep a hard coded test so 127.x.y.z address (and
> >> IPv6 equivalent) are never used (even if included or not excluded) for
> >> node communication
> >> Cheers,
> >> Gilles
> >> "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> wrote:
> >> >On Sep 21, 2016, at 10:56 AM, George Bosilca <bosi...@icl.utk.edu>
> >> >>
> >> >> No, because 127.x.x.x is by default part of the exclude, so it will
> >> >> never get into the modex. The problem today, is that even if you
> >> >> remove it from the exclude and add it to the include, it will not
> >> >> because of the hardcoded checks. Once we remove those checks, things
> >> >> work the way we expect, interfaces are removed because they don't
> match the
> >> >> provided addresses.
> >> >
> >> >Gotcha.
> >> >
> >> >> I would have agreed with you if the current code was doing a better
> >> >> decision of what is local and what not. But it is not, it simply
> remove all
> >> >> 127.x.x.x interfaces (opal/util/net.c:222). Thus, the only thing the
> >> >> code does, is preventing a power-user from using the loopback
> (despite being
> >> >> explicitly enabled via the corresponding MCA parameters).
> >> >
> >> >Fair enough.
> >> >
> >> >Should we have a keyword that can be used in the
> >> > btl_tcp_if_include/exclude (e.g., "local") that removes all local-only
> >> > interfaces? I.E., all 127.x.x.x/8 interfaces *and* all local-only
> >> > interfaces (e.g., bridging interfaces to local VMs and the like)?
> >> >
> >> >We could then replace the default "127.0.0.0/8" value in
> >> > btl_tcp_if_exclude with this token, and therefore actually exclude the
> >> > VM-only interfaces (which have caused some users problems in the
> >> >
> >> >--
> >> >Jeff Squyres
> >> >jsquy...@cisco.com
> >> >For corporate legal information go to:
> >> > http://www.cisco.com/web/about/doing_business/legal/cri/
> >> >
> >> >_______________________________________________
> >> >devel mailing list
> >> >email@example.com
> >> >https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> >> _______________________________________________
> >> devel mailing list
> >> firstname.lastname@example.org
> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> > _______________________________________________
> > devel mailing list
> > email@example.com
> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> devel mailing list
devel mailing list