Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-22 Thread Ulf Samuelsson
On 04/22/2015 12:46 PM, YOSHIFUJI Hideaki wrote: Ulf Samuelsson wrote: On 04/21/2015 05:58 AM, YOSHIFUJI Hideaki wrote: Ulf Samuelsson wrote: How many neighbors do you want to maintain? I guess you have to increase the number of gc_thresh1. The current use cases have up to 2048 entries. This

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-22 Thread YOSHIFUJI Hideaki
Ulf Samuelsson wrote: > > On 04/21/2015 05:58 AM, YOSHIFUJI Hideaki wrote: >> Ulf Samuelsson wrote: How many neighbors do you want to maintain? I guess you have to increase the number of gc_thresh1. >>> The current use cases have up to 2048 entries. >>> This is expected to grow in the fu

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-22 Thread Ulf Samuelsson
On 04/21/2015 05:58 AM, YOSHIFUJI Hideaki wrote: Ulf Samuelsson wrote: How many neighbors do you want to maintain? I guess you have to increase the number of gc_thresh1. The current use cases have up to 2048 entries. This is expected to grow in the future. The 3.4 kernel used in the system tod

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-20 Thread YOSHIFUJI Hideaki
Ulf Samuelsson wrote: >> How many neighbors do you want to maintain? >> I guess you have to increase the number of gc_thresh1. > The current use cases have up to 2048 entries. > This is expected to grow in the future. > The 3.4 kernel used in the system today is limited to 1024, > but that has been

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-20 Thread Ulf Samuelsson
On 04/20/2015 04:33 AM, YOSHIFUJI Hideaki wrote: Hi, Ulf Samuelsson wrote: From RFC2461: | REACHABLE Roughly speaking, the neighbor is known to have been | reachable recently (within tens of seconds ago). : | STALE The neighbor is no longer known to be rea

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-19 Thread YOSHIFUJI Hideaki
Hi, Ulf Samuelsson wrote: >> From RFC2461: >> >> | REACHABLE Roughly speaking, the neighbor is known to have been >> | reachable recently (within tens of seconds ago). >> : >> | STALE The neighbor is no longer known to be reachable but >> | unti

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-17 Thread Ulf Samuelsson
On 04/16/2015 07:16 AM, YOSHIFUJI Hideaki wrote: Hi, Ulf Samuelsson wrote: The desired functionality is that if communication stops, you want to send out ARP probes, before the entry is deleted. The current (pseudo) code of the neigh timer is: if (state & NUD_REACHABLE) { if (

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-15 Thread YOSHIFUJI Hideaki
Hi, Ulf Samuelsson wrote: > The desired functionality is that if communication stops, > you want to send out ARP probes, before the entry is deleted. > > The current (pseudo) code of the neigh timer is: > > if (state & NUD_REACHABLE) { > if (now <= "confirmed + "reachable_time")) {

Re: [PATCH] neighbour.c: Avoid GC directly after state change

2015-04-15 Thread Ulf Samuelsson
No reply on this in net/core/neighbour.c: neigh_timer_handler I see: if (state & NUD_REACHABLE) { if (time_before_eq(now, neigh->confirmed + neigh->parms->reachable_time)) { neigh_dbg(2, "neigh %p is still alive\n", neigh); next = neigh-