* [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).