* [RFC] net/core: Delay neighbor only if it has been used after confirmed @ 2009-09-02 9:17 Jens Rosenboom 2009-09-02 12:22 ` YOSHIFUJI Hideaki 0 siblings, 1 reply; 6+ messages in thread From: Jens Rosenboom @ 2009-09-02 9:17 UTC (permalink / raw) To: Linux Network Developers When doing some IPv6 testing with the router advertising a small (e.g. 5 seconds) reachable time, I noticed that after the traffic has stopped, hosts continue to exchange ND packets every 10 seconds. This is due to neigh_timer_handler() only checking neigh->used and puts a neighbor into NUD_DELAY state even if neigh->confirmed may be >= neigh->used. The following patch for net-next-2.6 fixes this behaviour for my IPv6 setup, however I would like to hear some opinion on whether this might have some negative influence on other protocols that use this code. I also think that it would make more sense to compute the time for the delay timer starting from neigh->used instead of using now (second part of the patch). diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 5bc4ad5..ca20162 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -820,12 +820,13 @@ static void neigh_timer_handler(unsigned long arg) NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); next = neigh->confirmed + neigh->parms->reachable_time; } else if (time_before_eq(now, - neigh->used + neigh->parms->delay_probe_time)) { + neigh->used + neigh->parms->delay_probe_time) && + time_after(neigh->confirmed, neigh->used)) { NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); neigh->nud_state = NUD_DELAY; neigh->updated = jiffies; neigh_suspect(neigh); - next = now + neigh->parms->delay_probe_time; + next = neigh->used + neigh->parms->delay_probe_time; } else { NEIGH_PRINTK2("neigh %p is suspected.\n", neigh); neigh->nud_state = NUD_STALE; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [RFC] net/core: Delay neighbor only if it has been used after confirmed 2009-09-02 9:17 [RFC] net/core: Delay neighbor only if it has been used after confirmed Jens Rosenboom @ 2009-09-02 12:22 ` YOSHIFUJI Hideaki 2009-09-02 13:03 ` Jens Rosenboom 2009-09-10 16:21 ` Jens Rosenboom 0 siblings, 2 replies; 6+ messages in thread From: YOSHIFUJI Hideaki @ 2009-09-02 12:22 UTC (permalink / raw) To: Jens Rosenboom; +Cc: Linux Network Developers, YOSHIFUJI Hideaki Hello. Jens Rosenboom wrote: > When doing some IPv6 testing with the router advertising a small (e.g. 5 > seconds) reachable time, I noticed that after the traffic has stopped, > hosts continue to exchange ND packets every 10 seconds. This is due to > neigh_timer_handler() only checking neigh->used and puts a neighbor into > NUD_DELAY state even if neigh->confirmed may be >= neigh->used. Well, as you can see in neigh_periodic_timer(): | if (time_before(n->used, n->confirmed)) | n->used = n->confirmed; time_after_eq(n->used, n->confirmed) should be taken valid; confirmed <= used <= now <= jiffies > The following patch for net-next-2.6 fixes this behaviour for my IPv6 > setup, however I would like to hear some opinion on whether this might > have some negative influence on other protocols that use this code. > > I also think that it would make more sense to compute the time for the > delay timer starting from neigh->used instead of using now (second part > of the patch). okay, but I would rather have this in another patch. > diff --git a/net/core/neighbour.c b/net/core/neighbour.c > index 5bc4ad5..ca20162 100644 > --- a/net/core/neighbour.c > +++ b/net/core/neighbour.c > @@ -820,12 +820,13 @@ static void neigh_timer_handler(unsigned long arg) > NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); > next = neigh->confirmed + neigh->parms->reachable_time; > } else if (time_before_eq(now, > - neigh->used + neigh->parms->delay_probe_time)) { > + neigh->used + neigh->parms->delay_probe_time) && > + time_after(neigh->confirmed, neigh->used)) { > NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); > neigh->nud_state = NUD_DELAY; I think your change should be | time_after(neigh->used, neigh->confirmed) or | time_before(neigh->confirmed, neigh->used) ("_eq" is removed because there is a little chance that the neighbor had been confirmed just before it was used. It is not interesting for us at this moment.) No? And, this "if" for REACHABLE->DELAY may be completely needless. Timer in REACHABLE is only for state transition for toward REACHABLE or STALE. --yoshfuji ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net/core: Delay neighbor only if it has been used after confirmed 2009-09-02 12:22 ` YOSHIFUJI Hideaki @ 2009-09-02 13:03 ` Jens Rosenboom 2009-09-10 16:21 ` Jens Rosenboom 1 sibling, 0 replies; 6+ messages in thread From: Jens Rosenboom @ 2009-09-02 13:03 UTC (permalink / raw) To: YOSHIFUJI Hideaki; +Cc: Linux Network Developers On Wed, 2009-09-02 at 21:22 +0900, YOSHIFUJI Hideaki wrote: > Hello. > > Jens Rosenboom wrote: > > When doing some IPv6 testing with the router advertising a small (e.g. 5 > > seconds) reachable time, I noticed that after the traffic has stopped, > > hosts continue to exchange ND packets every 10 seconds. This is due to > > neigh_timer_handler() only checking neigh->used and puts a neighbor into > > NUD_DELAY state even if neigh->confirmed may be >= neigh->used. > > Well, as you can see in neigh_periodic_timer(): > | if (time_before(n->used, n->confirmed)) > | n->used = n->confirmed; > time_after_eq(n->used, n->confirmed) should be taken valid; > confirmed <= used <= now <= jiffies Isn't there a chance that neigh_timer_handler() is run before the periodic timer fixes this? Otherwise I agree that the test could just say (n->used != n->confirmed). > > The following patch for net-next-2.6 fixes this behaviour for my IPv6 > > setup, however I would like to hear some opinion on whether this might > > have some negative influence on other protocols that use this code. > > > > I also think that it would make more sense to compute the time for the > > delay timer starting from neigh->used instead of using now (second part > > of the patch). > > okay, but I would rather have this in another patch. > > > diff --git a/net/core/neighbour.c b/net/core/neighbour.c > > index 5bc4ad5..ca20162 100644 > > --- a/net/core/neighbour.c > > +++ b/net/core/neighbour.c > > @@ -820,12 +820,13 @@ static void neigh_timer_handler(unsigned long arg) > > NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); > > next = neigh->confirmed + neigh->parms->reachable_time; > > } else if (time_before_eq(now, > > - neigh->used + neigh->parms->delay_probe_time)) { > > + neigh->used + neigh->parms->delay_probe_time) && > > + time_after(neigh->confirmed, neigh->used)) { > > NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); > > neigh->nud_state = NUD_DELAY; > > I think your change should be > | time_after(neigh->used, neigh->confirmed) > or > | time_before(neigh->confirmed, neigh->used) > > ("_eq" is removed because there is a little chance > that the neighbor had been confirmed just before it was > used. It is not interesting for us at this moment.) > > No? Yes, you are right, this test should be reversed. But together with your remarks above, this probably means that the whole stuff also works fine if we completely remove this if-branch. > And, this "if" for REACHABLE->DELAY may be completely needless. > Timer in REACHABLE is only for state transition for toward REACHABLE > or STALE. Well, this part has been there for a long time, at least it looks pretty much the same in the first git version, so I would be a bit reluctant to completely remove it, but since that would probably also solve my problem, I also wouldn't object that proposition. ;-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net/core: Delay neighbor only if it has been used after confirmed 2009-09-02 12:22 ` YOSHIFUJI Hideaki 2009-09-02 13:03 ` Jens Rosenboom @ 2009-09-10 16:21 ` Jens Rosenboom 2009-09-15 10:07 ` Jens Rosenboom 1 sibling, 1 reply; 6+ messages in thread From: Jens Rosenboom @ 2009-09-10 16:21 UTC (permalink / raw) To: YOSHIFUJI Hideaki; +Cc: Linux Network Developers On Wed, 2009-09-02 at 21:22 +0900, YOSHIFUJI Hideaki wrote: [...] > And, this "if" for REACHABLE->DELAY may be completely needless. > Timer in REACHABLE is only for state transition for toward REACHABLE > or STALE. I did some testing with the following patch, which works fine for me, so I propose this one now instead of my previous one. I still have no real idea about the non-IPv6 implications of this, though. --- diff --git a/net/core/neighbour.c b/net/core/neighbour.c index e587e68..f61926f 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -819,13 +819,6 @@ static void neigh_timer_handler(unsigned long arg) neigh->confirmed + neigh->parms->reachable_time)) { NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); next = neigh->confirmed + neigh->parms->reachable_time; - } else if (time_before_eq(now, - neigh->used + neigh->parms->delay_probe_time)) { - NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); - neigh->nud_state = NUD_DELAY; - neigh->updated = jiffies; - neigh_suspect(neigh); - next = now + neigh->parms->delay_probe_time; } else { NEIGH_PRINTK2("neigh %p is suspected.\n", neigh); neigh->nud_state = NUD_STALE; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [RFC] net/core: Delay neighbor only if it has been used after confirmed 2009-09-10 16:21 ` Jens Rosenboom @ 2009-09-15 10:07 ` Jens Rosenboom 2009-09-15 10:13 ` David Miller 0 siblings, 1 reply; 6+ messages in thread From: Jens Rosenboom @ 2009-09-15 10:07 UTC (permalink / raw) To: David Miller; +Cc: Linux Network Developers, YOSHIFUJI Hideaki On Thu, 2009-09-10 at 18:21 +0200, Jens Rosenboom wrote: > On Wed, 2009-09-02 at 21:22 +0900, YOSHIFUJI Hideaki wrote: > [...] > > And, this "if" for REACHABLE->DELAY may be completely needless. > > Timer in REACHABLE is only for state transition for toward REACHABLE > > or STALE. > > I did some testing with the following patch, which works fine for me, so > I propose this one now instead of my previous one. I still have no real > idea about the non-IPv6 implications of this, though. > > --- > > diff --git a/net/core/neighbour.c b/net/core/neighbour.c > index e587e68..f61926f 100644 > --- a/net/core/neighbour.c > +++ b/net/core/neighbour.c > @@ -819,13 +819,6 @@ static void neigh_timer_handler(unsigned long arg) > neigh->confirmed + neigh->parms->reachable_time)) { > NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); > next = neigh->confirmed + neigh->parms->reachable_time; > - } else if (time_before_eq(now, > - neigh->used + neigh->parms->delay_probe_time)) { > - NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); > - neigh->nud_state = NUD_DELAY; > - neigh->updated = jiffies; > - neigh_suspect(neigh); > - next = now + neigh->parms->delay_probe_time; > } else { > NEIGH_PRINTK2("neigh %p is suspected.\n", neigh); > neigh->nud_state = NUD_STALE; > Hi David, what are your thoughts on this one? There is IMHO a real bug to fix, namely sending tons of repeated neighbor solicitations when there is no actual traffic to be sent, so this should qualify to go into 2.6.32. Do you want to wait for further comments or should I submit this for net-2.6 so it can get some testing? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net/core: Delay neighbor only if it has been used after confirmed 2009-09-15 10:07 ` Jens Rosenboom @ 2009-09-15 10:13 ` David Miller 0 siblings, 0 replies; 6+ messages in thread From: David Miller @ 2009-09-15 10:13 UTC (permalink / raw) To: jens; +Cc: netdev, yoshfuji From: Jens Rosenboom <jens@mcbone.net> Date: Tue, 15 Sep 2009 12:07:26 +0200 > On Thu, 2009-09-10 at 18:21 +0200, Jens Rosenboom wrote: >> On Wed, 2009-09-02 at 21:22 +0900, YOSHIFUJI Hideaki wrote: >> [...] >> > And, this "if" for REACHABLE->DELAY may be completely needless. >> > Timer in REACHABLE is only for state transition for toward REACHABLE >> > or STALE. >> >> I did some testing with the following patch, which works fine for me, so >> I propose this one now instead of my previous one. I still have no real >> idea about the non-IPv6 implications of this, though. >> >> --- >> >> diff --git a/net/core/neighbour.c b/net/core/neighbour.c >> index e587e68..f61926f 100644 >> --- a/net/core/neighbour.c >> +++ b/net/core/neighbour.c >> @@ -819,13 +819,6 @@ static void neigh_timer_handler(unsigned long arg) >> neigh->confirmed + neigh->parms->reachable_time)) { >> NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); >> next = neigh->confirmed + neigh->parms->reachable_time; >> - } else if (time_before_eq(now, >> - neigh->used + neigh->parms->delay_probe_time)) { >> - NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); >> - neigh->nud_state = NUD_DELAY; >> - neigh->updated = jiffies; >> - neigh_suspect(neigh); >> - next = now + neigh->parms->delay_probe_time; >> } else { >> NEIGH_PRINTK2("neigh %p is suspected.\n", neigh); >> neigh->nud_state = NUD_STALE; >> > > Hi David, what are your thoughts on this one? There is IMHO a real bug > to fix, namely sending tons of repeated neighbor solicitations when > there is no actual traffic to be sent, so this should qualify to go into > 2.6.32. Do you want to wait for further comments or should I submit this > for net-2.6 so it can get some testing? I'm waiting for Yoshifuji's feedback to your latest patch. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-09-15 10:13 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-09-02 9:17 [RFC] net/core: Delay neighbor only if it has been used after confirmed Jens Rosenboom 2009-09-02 12:22 ` YOSHIFUJI Hideaki 2009-09-02 13:03 ` Jens Rosenboom 2009-09-10 16:21 ` Jens Rosenboom 2009-09-15 10:07 ` Jens Rosenboom 2009-09-15 10:13 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).