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

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 future. The 3.4

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.

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 raised

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

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 | until traffic is

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 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 =

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)) {