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 



"Jeff Squyres (jsquyres)" <> wrote:
>On Sep 21, 2016, at 10:56 AM, George Bosilca <> 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.
>> 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 "" 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
>For corporate legal information go to: 
>devel mailing list
devel mailing list

Reply via email to