FWIW: you know the location of every proc (to at least the host level) from time of orte_init, which should precede anything in the BTL
> On Sep 21, 2016, at 8:31 AM, 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 inter 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> wrote: >>> >>> 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 manually remove >>> it from the exclude and add it to the include, it will not work, because of >>> the hardcoded checks. Once we remove those checks, things will 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 >>> current 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 past). >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> devel mailing list >> devel@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
