RFC applied via 93fa94f9.
On Fri, Sep 23, 2016 at 7:13 AM, George Bosilca wrote:
> It turns out the OMPI behavior today was divergent from what is written in
> the README. We already explicitly state that
>
> - If specified, the "btl_tcp_if_exclude" parameter must include the
> loopback d
It turns out the OMPI behavior today was divergent from what is written in
the README. We already explicitly state that
- If specified, the "btl_tcp_if_exclude" parameter must include the
loopback device ("lo" on many Linux platforms), or Open MPI will
not be able to route MPI messages u
George,
OK then,
I recommend we explicitly state in the README that loopback interface can
no more be omitted from btl_tcp_if_exclude when running on multiple nodes
Cheers,
Gilles
On Thursday, September 22, 2016, George Bosilca wrote:
> Thanks for clarifying, I now understand what your object
Thanks for clarifying, I now understand what your objection/suggestion was.
We all misconfigured OMPI at least once, but that allowed us to learn how
to do it right.
Instead of adding extra protections for corner-cases, maybe we should fix
our exclusivity flag so that the scenario you describe wou
ok, i was not clear
by "let's consider the case where "lo" is *not* excluded via the
btl_tcp_if_exclude MCA param" i really meant
"let's consider the case where the value of the btl_tcp_if_exclude MCA
param has been forced to a list of network/interfaces that do not
contain any reference (e.g. nam
On Wednesday, September 21, 2016, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:
> George,
>
> let's consider the case where "lo" is *not* excluded via the
> btl_tcp_if_exclude MCA param
> (if i understand correctly, the following is also true if "lo" is
> included via the btl_tcp_if_
George,
let's consider the case where "lo" is *not* excluded via the
btl_tcp_if_exclude MCA param
(if i understand correctly, the following is also true if "lo" is
included via the btl_tcp_if_include MCA param)
currently, and because of/thanks to the test that is done "deep inside"
1) on a discon
Gilles,
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 hav
On Wed, Sep 21, 2016 at 9:36 AM, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:
>
> 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 no
George,
i got that, and i consider my suggestion as an improvement to your proposal.
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
My proposal is not about adding new ways of deciding what is local and what
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:
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
> wrote:
>
> George,
>
> Is proc locality already set at that time ?
>
> If yes, then we could keep a har
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)" wrote:
>On Sep 21, 2016, at 10:
13 matches
Mail list logo