Hi,
I'm having problems forming a TIPC cluster between 2 nodes.
This is the basic steps I'm going through on each node.
modprobe tipc
ip link set eth2 up
tipc node set addr 1.1.5 # or 1.1.6
tipc bearer enable media eth dev eth0
Then to confirm if the cluster is formed I use tipc link list
[root@node-5 ~]# tipc link list
broadcast-link: up
...
Looking at tcpdump the two nodes are sending packets
22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
MessageSize 76 bytes, Neighbor Detection Protocol internal, messageType
Link request
22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
MessageSize 76 bytes, Neighbor Detection Protocol internal, messageType
Link request
Eventually (after a few minutes) the link does come up
[root@node-6 ~]# tipc link list
broadcast-link: up
1001006:eth2-1001005:eth2: up
[root@node-5 ~]# tipc link list
broadcast-link: up
1001005:eth2-1001006:eth2: up
When I remove the "tipc node set addr" things seem to kick into life
straight away
[root@node-5 ~]# tipc link list
broadcast-link: up
0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
So there appears to be some difference in behaviour between having an
explicit node address and using the default. Unfortunately our
application relies on setting the node addresses.
[root@node-5 ~]# uname -a
Linux linuxbox 5.2.0-at1+ #8 SMP Thu Jul 25 23:22:41 UTC 2019 ppc
GNU/Linux
Any thoughts on the problem?
> -----Original Message-----
> From: [email protected] <[email protected]> On
> Behalf Of Chris Packham
> Sent: 25-Jul-19 19:37
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Slowness forming TIPC cluster with explicit node addresses
>
> Hi,
>
> I'm having problems forming a TIPC cluster between 2 nodes.
>
> This is the basic steps I'm going through on each node.
>
> modprobe tipc
> ip link set eth2 up
> tipc node set addr 1.1.5 # or 1.1.6
> tipc bearer enable media eth dev eth0
eth2, I assume...
>
> Then to confirm if the cluster is formed I use tipc link list
>
> [root@node-5 ~]# tipc link list
> broadcast-link: up
> ...
>
> Looking at tcpdump the two nodes are sending packets
>
> 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes, MessageSize
> 76 bytes, Neighbor Detection Protocol internal, messageType Link request
> 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes, MessageSize
> 76 bytes, Neighbor Detection Protocol internal, messageType Link request
>
> Eventually (after a few minutes) the link does come up
>
> [root@node-6 ~]# tipc link list
> broadcast-link: up
> 1001006:eth2-1001005:eth2: up
>
> [root@node-5 ~]# tipc link list
> broadcast-link: up
> 1001005:eth2-1001006:eth2: up
>
> When I remove the "tipc node set addr" things seem to kick into life straight
> away
>
> [root@node-5 ~]# tipc link list
> broadcast-link: up
> 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
>
> So there appears to be some difference in behaviour between having an
> explicit node address and using the default. Unfortunately our application
> relies on setting the node addresses.
I do this many times a day, without any problems. If there would be any time difference, I would expect the 'auto configurable' version to be slower, because it involves a DAD step.
Are you sure you don't have any other nodes running in your system?
///jon
>
> [root@node-5 ~]# uname -a
> Linux linuxbox 5.2.0-at1+ #8 SMP Thu Jul 25 23:22:41 UTC 2019 ppc
> GNU/Linux
>
> Any thoughts on the problem?
On Fri, 2019-07-26 at 13:31 +0000, Jon Maloy wrote:
>
> >
> > -----Original Message-----
> > From: [email protected] <[email protected]>
> > On
> > Behalf Of Chris Packham
> > Sent: 25-Jul-19 19:37
> > To: [email protected]
> > Cc: [email protected]; [email protected]
> > Subject: Slowness forming TIPC cluster with explicit node addresses
> >
> > Hi,
> >
> > I'm having problems forming a TIPC cluster between 2 nodes.
> >
> > This is the basic steps I'm going through on each node.
> >
> > modprobe tipc
> > ip link set eth2 up
> > tipc node set addr 1.1.5 # or 1.1.6
> > tipc bearer enable media eth dev eth0
> eth2, I assume...
>
Yes sorry I keep switching between between Ethernet ports for testing
so I hand edited the email.
> >
> >
> > Then to confirm if the cluster is formed I use tipc link list
> >
> > [root@node-5 ~]# tipc link list
> > broadcast-link: up
> > ...
> >
> > Looking at tcpdump the two nodes are sending packets
> >
> > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
> > MessageSize
> > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > request
> > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
> > MessageSize
> > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > request
> >
> > Eventually (after a few minutes) the link does come up
> >
> > [root@node-6 ~]# tipc link list
> > broadcast-link: up
> > 1001006:eth2-1001005:eth2: up
> >
> > [root@node-5 ~]# tipc link list
> > broadcast-link: up
> > 1001005:eth2-1001006:eth2: up
> >
> > When I remove the "tipc node set addr" things seem to kick into
> > life straight
> > away
> >
> > [root@node-5 ~]# tipc link list
> > broadcast-link: up
> > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> >
> > So there appears to be some difference in behaviour between having
> > an
> > explicit node address and using the default. Unfortunately our
> > application
> > relies on setting the node addresses.
> I do this many times a day, without any problems. If there would be
> any time difference, I would expect the 'auto configurable' version
> to be slower, because it involves a DAD step.
> Are you sure you don't have any other nodes running in your system?
>
> ///jon
>
Nope the two nodes are connected back to back. Does the number of
Ethernet interfaces make a difference? As you can see I've got 3 on
each node. One is completely disconnected, one is for booting over TFTP
(only used by U-boot) and the other is the USB Ethernet I'm using for
testing.
>
> >
> >
> > [root@node-5 ~]# uname -a
> > Linux linuxbox 5.2.0-at1+ #8 SMP Thu Jul 25 23:22:41 UTC 2019 ppc
> > GNU/Linux
> >
> > Any thoughts on the problem?
On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> On Fri, 2019-07-26 at 13:31 +0000, Jon Maloy wrote:
> >
> >
> > >
> > >
> > > -----Original Message-----
> > > From: [email protected] <[email protected]>
> > > On
> > > Behalf Of Chris Packham
> > > Sent: 25-Jul-19 19:37
> > > To: [email protected]
> > > Cc: [email protected]; [email protected]
> > > Subject: Slowness forming TIPC cluster with explicit node
> > > addresses
> > >
> > > Hi,
> > >
> > > I'm having problems forming a TIPC cluster between 2 nodes.
> > >
> > > This is the basic steps I'm going through on each node.
> > >
> > > modprobe tipc
> > > ip link set eth2 up
> > > tipc node set addr 1.1.5 # or 1.1.6
> > > tipc bearer enable media eth dev eth0
> > eth2, I assume...
> >
> Yes sorry I keep switching between between Ethernet ports for testing
> so I hand edited the email.
>
> >
> > >
> > >
> > >
> > > Then to confirm if the cluster is formed I use tipc link list
> > >
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > ...
> > >
> > > Looking at tcpdump the two nodes are sending packets
> > >
> > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
> > > MessageSize
> > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > request
> > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
> > > MessageSize
> > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > request
> > >
> > > Eventually (after a few minutes) the link does come up
> > >
> > > [root@node-6 ~]# tipc link list
> > > broadcast-link: up
> > > 1001006:eth2-1001005:eth2: up
> > >
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > 1001005:eth2-1001006:eth2: up
> > >
> > > When I remove the "tipc node set addr" things seem to kick into
> > > life straight
> > > away
> > >
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > >
> > > So there appears to be some difference in behaviour between
> > > having
> > > an
> > > explicit node address and using the default. Unfortunately our
> > > application
> > > relies on setting the node addresses.
> > I do this many times a day, without any problems. If there would be
> > any time difference, I would expect the 'auto configurable' version
> > to be slower, because it involves a DAD step.
> > Are you sure you don't have any other nodes running in your system?
> >
> > ///jon
> >
> Nope the two nodes are connected back to back. Does the number of
> Ethernet interfaces make a difference? As you can see I've got 3 on
> each node. One is completely disconnected, one is for booting over
> TFTP
> (only used by U-boot) and the other is the USB Ethernet I'm using
> for
> testing.
>
So I can still reproduce this on nodes that only have one network
interface and are the only things connected.
I did find one thing that helps
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index c138d68e8a69..49921dad404a 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
tipc_bearer *b,
tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
/* Do we need an address trial period first ? */
- if (!tipc_own_addr(net)) {
+// if (!tipc_own_addr(net)) {
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
- }
+// }
memcpy(&d->dest, dest, sizeof(*dest));
d->net = net;
d->bearer_id = b->identity;
I think because with pre-configured addresses the duplicate address
detection is skipped the shorter init phase is skipped. Would is make
sense to unconditionally do the trial step? Or is there some better way
to get things to transition with pre-assigned addresses.
> -----Original Message-----
> From: [email protected] <[email protected]> On
> Behalf Of Chris Packham
> Sent: 2-Aug-19 01:11
> To: Jon Maloy <[email protected]>; tipc-
> [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: Slowness forming TIPC cluster with explicit node addresses
>
> On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> > On Fri, 2019-07-26 at 13:31 +0000, Jon Maloy wrote:
> > >
> > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email protected] <netdev-
> [email protected]>
> > > > On Behalf Of Chris Packham
> > > > Sent: 25-Jul-19 19:37
> > > > To: [email protected]
> > > > Cc: [email protected]; [email protected]
> > > > Subject: Slowness forming TIPC cluster with explicit node
> > > > addresses
> > > >
> > > > Hi,
> > > >
> > > > I'm having problems forming a TIPC cluster between 2 nodes.
> > > >
> > > > This is the basic steps I'm going through on each node.
> > > >
> > > > modprobe tipc
> > > > ip link set eth2 up
> > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media eth
> > > > dev eth0
> > > eth2, I assume...
> > >
> > Yes sorry I keep switching between between Ethernet ports for testing
> > so I hand edited the email.
> >
> > >
> > > >
> > > >
> > > >
> > > > Then to confirm if the cluster is formed I use tipc link list
> > > >
> > > > [root@node-5 ~]# tipc link list
> > > > broadcast-link: up
> > > > ...
> > > >
> > > > Looking at tcpdump the two nodes are sending packets
> > > >
> > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
> > > > MessageSize
> > > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > > request
> > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
> > > > MessageSize
> > > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > > request
> > > >
> > > > Eventually (after a few minutes) the link does come up
> > > >
> > > > [root@node-6 ~]# tipc link list
> > > > broadcast-link: up
> > > > 1001006:eth2-1001005:eth2: up
> > > >
> > > > [root@node-5 ~]# tipc link list
> > > > broadcast-link: up
> > > > 1001005:eth2-1001006:eth2: up
> > > >
> > > > When I remove the "tipc node set addr" things seem to kick into
> > > > life straight away
> > > >
> > > > [root@node-5 ~]# tipc link list
> > > > broadcast-link: up
> > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > >
> > > > So there appears to be some difference in behaviour between having
> > > > an explicit node address and using the default. Unfortunately our
> > > > application relies on setting the node addresses.
> > > I do this many times a day, without any problems. If there would be
> > > any time difference, I would expect the 'auto configurable' version
> > > to be slower, because it involves a DAD step.
> > > Are you sure you don't have any other nodes running in your system?
> > >
> > > ///jon
> > >
> > Nope the two nodes are connected back to back. Does the number of
> > Ethernet interfaces make a difference? As you can see I've got 3 on
> > each node. One is completely disconnected, one is for booting over
> > TFTP
> > (only used by U-boot) and the other is the USB Ethernet I'm using for
> > testing.
> >
>
> So I can still reproduce this on nodes that only have one network interface and
> are the only things connected.
>
> I did find one thing that helps
>
> diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> c138d68e8a69..49921dad404a 100644
> --- a/net/tipc/discover.c
> +++ b/net/tipc/discover.c
> @@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
> tipc_bearer *b,
> tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
>
> /* Do we need an address trial period first ? */
> - if (!tipc_own_addr(net)) {
> +// if (!tipc_own_addr(net)) {
> tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
> msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
> - }
> +// }
> memcpy(&d->dest, dest, sizeof(*dest));
> d->net = net;
> d->bearer_id = b->identity;
>
> I think because with pre-configured addresses the duplicate address detection
> is skipped the shorter init phase is skipped. Would is make sense to
> unconditionally do the trial step? Or is there some better way to get things to
> transition with pre-assigned addresses.
I am on vacation until the end of next-week, so I can't give you any good analysis right now.
To do the trial step doesn’t make much sense to me, -it would only delay the setup unnecessarily (but with only 1 second).
Can you check the initial value of addr_trial_end when there a pre-configured address?
///jon
On Sun, 2019-08-04 at 21:53 +0000, Jon Maloy wrote:
>
> >
> > -----Original Message-----
> > From: [email protected] <[email protected]>
> > On
> > Behalf Of Chris Packham
> > Sent: 2-Aug-19 01:11
> > To: Jon Maloy <[email protected]>; tipc-
> > [email protected]
> > Cc: [email protected]; [email protected]
> > Subject: Re: Slowness forming TIPC cluster with explicit node
> > addresses
> >
> > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> > >
> > > On Fri, 2019-07-26 at 13:31 +0000, Jon Maloy wrote:
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email protected] <netdev-
> > [email protected]>
> > >
> > > >
> > > > >
> > > > > On Behalf Of Chris Packham
> > > > > Sent: 25-Jul-19 19:37
> > > > > To: [email protected]
> > > > > Cc: [email protected]; [email protected]
> > > > > Subject: Slowness forming TIPC cluster with explicit node
> > > > > addresses
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm having problems forming a TIPC cluster between 2 nodes.
> > > > >
> > > > > This is the basic steps I'm going through on each node.
> > > > >
> > > > > modprobe tipc
> > > > > ip link set eth2 up
> > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media
> > > > > eth
> > > > > dev eth0
> > > > eth2, I assume...
> > > >
> > > Yes sorry I keep switching between between Ethernet ports for
> > > testing
> > > so I hand edited the email.
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Then to confirm if the cluster is formed I use tipc link list
> > > > >
> > > > > [root@node-5 ~]# tipc link list
> > > > > broadcast-link: up
> > > > > ...
> > > > >
> > > > > Looking at tcpdump the two nodes are sending packets
> > > > >
> > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60
> > > > > bytes,
> > > > > MessageSize
> > > > > 76 bytes, Neighbor Detection Protocol internal, messageType
> > > > > Link
> > > > > request
> > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60
> > > > > bytes,
> > > > > MessageSize
> > > > > 76 bytes, Neighbor Detection Protocol internal, messageType
> > > > > Link
> > > > > request
> > > > >
> > > > > Eventually (after a few minutes) the link does come up
> > > > >
> > > > > [root@node-6 ~]# tipc link list
> > > > > broadcast-link: up
> > > > > 1001006:eth2-1001005:eth2: up
> > > > >
> > > > > [root@node-5 ~]# tipc link list
> > > > > broadcast-link: up
> > > > > 1001005:eth2-1001006:eth2: up
> > > > >
> > > > > When I remove the "tipc node set addr" things seem to kick
> > > > > into
> > > > > life straight away
> > > > >
> > > > > [root@node-5 ~]# tipc link list
> > > > > broadcast-link: up
> > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > > >
> > > > > So there appears to be some difference in behaviour between
> > > > > having
> > > > > an explicit node address and using the default. Unfortunately
> > > > > our
> > > > > application relies on setting the node addresses.
> > > > I do this many times a day, without any problems. If there
> > > > would be
> > > > any time difference, I would expect the 'auto configurable'
> > > > version
> > > > to be slower, because it involves a DAD step.
> > > > Are you sure you don't have any other nodes running in your
> > > > system?
> > > >
> > > > ///jon
> > > >
> > > Nope the two nodes are connected back to back. Does the number of
> > > Ethernet interfaces make a difference? As you can see I've got 3
> > > on
> > > each node. One is completely disconnected, one is for booting
> > > over
> > > TFTP
> > > (only used by U-boot) and the other is the USB Ethernet I'm
> > > using for
> > > testing.
> > >
> > So I can still reproduce this on nodes that only have one network
> > interface and
> > are the only things connected.
> >
> > I did find one thing that helps
> >
> > diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> > c138d68e8a69..49921dad404a 100644
> > --- a/net/tipc/discover.c
> > +++ b/net/tipc/discover.c
> > @@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
> > tipc_bearer *b,
> > tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
> >
> > /* Do we need an address trial period first ? */
> > - if (!tipc_own_addr(net)) {
> > +// if (!tipc_own_addr(net)) {
> > tn->addr_trial_end = jiffies +
> > msecs_to_jiffies(1000);
> > msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
> > - }
> > +// }
> > memcpy(&d->dest, dest, sizeof(*dest));
> > d->net = net;
> > d->bearer_id = b->identity;
> >
> > I think because with pre-configured addresses the duplicate address
> > detection
> > is skipped the shorter init phase is skipped. Would is make sense
> > to
> > unconditionally do the trial step? Or is there some better way to
> > get things to
> > transition with pre-assigned addresses.
>
> I am on vacation until the end of next-week, so I can't give you any
> good analysis right now.
Thanks for taking the time to respond.
> To do the trial step doesn’t make much sense to me, -it would only
> delay the setup unnecessarily (but with only 1 second).
> Can you check the initial value of addr_trial_end when there a pre-
> configured address?
I had the same thought. For both my devices 'addr_trial_end = 0' so I
think tipc_disc_addr_trial_msg should end up with trial == false
>
> ///jon
>
> -----Original Message-----
> From: Chris Packham <[email protected]>
> Sent: 4-Aug-19 19:05
> To: Jon Maloy <[email protected]>; tipc-
> [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: Slowness forming TIPC cluster with explicit node addresses
>
> On Sun, 2019-08-04 at 21:53 +0000, Jon Maloy wrote:
> >
> > >
> > > -----Original Message-----
> > > From: [email protected] <[email protected]>
> On
> > > Behalf Of Chris Packham
> > > Sent: 2-Aug-19 01:11
> > > To: Jon Maloy <[email protected]>; tipc-
> > > [email protected]
> > > Cc: [email protected]; [email protected]
> > > Subject: Re: Slowness forming TIPC cluster with explicit node
> > > addresses
> > >
> > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> > > >
> > > > On Fri, 2019-07-26 at 13:31 +0000, Jon Maloy wrote:
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email protected] <netdev-
> > > [email protected]>
> > > >
> > > > >
> > > > > >
> > > > > > On Behalf Of Chris Packham
> > > > > > Sent: 25-Jul-19 19:37
> > > > > > To: [email protected]
> > > > > > Cc: [email protected]; [email protected]
> > > > > > Subject: Slowness forming TIPC cluster with explicit node
> > > > > > addresses
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm having problems forming a TIPC cluster between 2 nodes.
> > > > > >
> > > > > > This is the basic steps I'm going through on each node.
> > > > > >
> > > > > > modprobe tipc
> > > > > > ip link set eth2 up
> > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media
> > > > > > eth dev eth0
> > > > > eth2, I assume...
> > > > >
> > > > Yes sorry I keep switching between between Ethernet ports for
> > > > testing
> > > > so I hand edited the email.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Then to confirm if the cluster is formed I use tipc link list
> > > > > >
> > > > > > [root@node-5 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > ...
> > > > > >
> > > > > > Looking at tcpdump the two nodes are sending packets
> > > > > >
> > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60
> > > > > > bytes,
> > > > > > MessageSize
> > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType
> > > > > > Link
> > > > > > request
> > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60
> > > > > > bytes,
> > > > > > MessageSize
> > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType
> > > > > > Link
> > > > > > request
> > > > > >
> > > > > > Eventually (after a few minutes) the link does come up
> > > > > >
> > > > > > [root@node-6 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > 1001006:eth2-1001005:eth2: up
> > > > > >
> > > > > > [root@node-5 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > 1001005:eth2-1001006:eth2: up
> > > > > >
> > > > > > When I remove the "tipc node set addr" things seem to kick
> > > > > > into
> > > > > > life straight away
> > > > > >
> > > > > > [root@node-5 ~]# tipc link list
> > > > > > broadcast-link: up
> > > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > > > >
> > > > > > So there appears to be some difference in behaviour between
> > > > > > having
> > > > > > an explicit node address and using the default. Unfortunately
> > > > > > our
> > > > > > application relies on setting the node addresses.
> > > > > I do this many times a day, without any problems. If there
> > > > > would be
> > > > > any time difference, I would expect the 'auto configurable'
> > > > > version
> > > > > to be slower, because it involves a DAD step.
> > > > > Are you sure you don't have any other nodes running in your
> > > > > system?
> > > > >
> > > > > ///jon
> > > > >
> > > > Nope the two nodes are connected back to back. Does the number of
> > > > Ethernet interfaces make a difference? As you can see I've got 3
> > > > on
> > > > each node. One is completely disconnected, one is for booting
> > > > over
> > > > TFTP
> > > > (only used by U-boot) and the other is the USB Ethernet I'm
> > > > using for
> > > > testing.
> > > >
> > > So I can still reproduce this on nodes that only have one network
> > > interface and
> > > are the only things connected.
> > >
> > > I did find one thing that helps
> > >
> > > diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> > > c138d68e8a69..49921dad404a 100644
> > > --- a/net/tipc/discover.c
> > > +++ b/net/tipc/discover.c
> > > @@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
> > > tipc_bearer *b,
> > > tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
> > >
> > > /* Do we need an address trial period first ? */
> > > - if (!tipc_own_addr(net)) {
> > > +// if (!tipc_own_addr(net)) {
> > > tn->addr_trial_end = jiffies +
> > > msecs_to_jiffies(1000);
> > > msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
> > > - }
> > > +// }
> > > memcpy(&d->dest, dest, sizeof(*dest));
> > > d->net = net;
> > > d->bearer_id = b->identity;
> > >
> > > I think because with pre-configured addresses the duplicate address
> > > detection
> > > is skipped the shorter init phase is skipped. Would is make sense
> > > to
> > > unconditionally do the trial step? Or is there some better way to
> > > get things to
> > > transition with pre-assigned addresses.
> >
> > I am on vacation until the end of next-week, so I can't give you any
> > good analysis right now.
>
> Thanks for taking the time to respond.
>
> > To do the trial step doesn’t make much sense to me, -it would only
> > delay the setup unnecessarily (but with only 1 second).
> > Can you check the initial value of addr_trial_end when there a pre-
> > configured address?
>
> I had the same thought. For both my devices 'addr_trial_end = 0' so I
> think tipc_disc_addr_trial_msg should end up with trial == false
I suggest you try initializing it to jiffies and see what happens.
///jon
>
> >
> > ///jon
> >
Hi Jon,
On Wed, 2019-08-07 at 02:55 +0000, Jon Maloy wrote:
>
> >
> > -----Original Message-----
> > From: Chris Packham <[email protected]>
> > Sent: 4-Aug-19 19:05
> > To: Jon Maloy <[email protected]>; tipc-
> > [email protected]
> > Cc: [email protected]; [email protected]
> > Subject: Re: Slowness forming TIPC cluster with explicit node
> > addresses
> >
> > On Sun, 2019-08-04 at 21:53 +0000, Jon Maloy wrote:
> > >
> > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email protected] <[email protected]
> > > > g>
> > On
> > >
> > > >
> > > > Behalf Of Chris Packham
> > > > Sent: 2-Aug-19 01:11
> > > > To: Jon Maloy <[email protected]>; tipc-
> > > > [email protected]
> > > > Cc: [email protected]; [email protected]
> > > > Subject: Re: Slowness forming TIPC cluster with explicit node
> > > > addresses
> > > >
> > > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> > > > >
> > > > >
> > > > > On Fri, 2019-07-26 at 13:31 +0000, Jon Maloy wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email protected] <netdev-
> > > > [email protected]>
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Behalf Of Chris Packham
> > > > > > > Sent: 25-Jul-19 19:37
> > > > > > > To: [email protected]
> > > > > > > Cc: [email protected]; [email protected]
> > > > > > > Subject: Slowness forming TIPC cluster with explicit node
> > > > > > > addresses
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm having problems forming a TIPC cluster between 2
> > > > > > > nodes.
> > > > > > >
> > > > > > > This is the basic steps I'm going through on each node.
> > > > > > >
> > > > > > > modprobe tipc
> > > > > > > ip link set eth2 up
> > > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable
> > > > > > > media
> > > > > > > eth dev eth0
> > > > > > eth2, I assume...
> > > > > >
> > > > > Yes sorry I keep switching between between Ethernet ports for
> > > > > testing
> > > > > so I hand edited the email.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Then to confirm if the cluster is formed I use tipc link
> > > > > > > list
> > > > > > >
> > > > > > > [root@node-5 ~]# tipc link list
> > > > > > > broadcast-link: up
> > > > > > > ...
> > > > > > >
> > > > > > > Looking at tcpdump the two nodes are sending packets
> > > > > > >
> > > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60
> > > > > > > bytes,
> > > > > > > MessageSize
> > > > > > > 76 bytes, Neighbor Detection Protocol internal,
> > > > > > > messageType
> > > > > > > Link
> > > > > > > request
> > > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60
> > > > > > > bytes,
> > > > > > > MessageSize
> > > > > > > 76 bytes, Neighbor Detection Protocol internal,
> > > > > > > messageType
> > > > > > > Link
> > > > > > > request
> > > > > > >
> > > > > > > Eventually (after a few minutes) the link does come up
> > > > > > >
> > > > > > > [root@node-6 ~]# tipc link list
> > > > > > > broadcast-link: up
> > > > > > > 1001006:eth2-1001005:eth2: up
> > > > > > >
> > > > > > > [root@node-5 ~]# tipc link list
> > > > > > > broadcast-link: up
> > > > > > > 1001005:eth2-1001006:eth2: up
> > > > > > >
> > > > > > > When I remove the "tipc node set addr" things seem to
> > > > > > > kick
> > > > > > > into
> > > > > > > life straight away
> > > > > > >
> > > > > > > [root@node-5 ~]# tipc link list
> > > > > > > broadcast-link: up
> > > > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > > > > >
> > > > > > > So there appears to be some difference in behaviour
> > > > > > > between
> > > > > > > having
> > > > > > > an explicit node address and using the default.
> > > > > > > Unfortunately
> > > > > > > our
> > > > > > > application relies on setting the node addresses.
> > > > > > I do this many times a day, without any problems. If there
> > > > > > would be
> > > > > > any time difference, I would expect the 'auto configurable'
> > > > > > version
> > > > > > to be slower, because it involves a DAD step.
> > > > > > Are you sure you don't have any other nodes running in your
> > > > > > system?
> > > > > >
> > > > > > ///jon
> > > > > >
> > > > > Nope the two nodes are connected back to back. Does the
> > > > > number of
> > > > > Ethernet interfaces make a difference? As you can see I've
> > > > > got 3
> > > > > on
> > > > > each node. One is completely disconnected, one is for booting
> > > > > over
> > > > > TFTP
> > > > > (only used by U-boot) and the other is the USB Ethernet I'm
> > > > > using for
> > > > > testing.
> > > > >
> > > > So I can still reproduce this on nodes that only have one
> > > > network
> > > > interface and
> > > > are the only things connected.
> > > >
> > > > I did find one thing that helps
> > > >
> > > > diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> > > > c138d68e8a69..49921dad404a 100644
> > > > --- a/net/tipc/discover.c
> > > > +++ b/net/tipc/discover.c
> > > > @@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net,
> > > > struct
> > > > tipc_bearer *b,
> > > > tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
> > > >
> > > > /* Do we need an address trial period first ? */
> > > > - if (!tipc_own_addr(net)) {
> > > > +// if (!tipc_own_addr(net)) {
> > > > tn->addr_trial_end = jiffies +
> > > > msecs_to_jiffies(1000);
> > > > msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
> > > > - }
> > > > +// }
> > > > memcpy(&d->dest, dest, sizeof(*dest));
> > > > d->net = net;
> > > > d->bearer_id = b->identity;
> > > >
> > > > I think because with pre-configured addresses the duplicate
> > > > address
> > > > detection
> > > > is skipped the shorter init phase is skipped. Would is make
> > > > sense
> > > > to
> > > > unconditionally do the trial step? Or is there some better way
> > > > to
> > > > get things to
> > > > transition with pre-assigned addresses.
> > > I am on vacation until the end of next-week, so I can't give you
> > > any
> > > good analysis right now.
> > Thanks for taking the time to respond.
> >
> > >
> > > To do the trial step doesn’t make much sense to me, -it would
> > > only
> > > delay the setup unnecessarily (but with only 1 second).
> > > Can you check the initial value of addr_trial_end when there a
> > > pre-
> > > configured address?
> > I had the same thought. For both my devices 'addr_trial_end = 0' so
> > I
> > think tipc_disc_addr_trial_msg should end up with trial == false
> I suggest you try initializing it to jiffies and see what happens.
>
Setting addr_trial_end to jiffies seems to do the trick. I'll prepare a
patch and send it through.