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

[YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>]

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 sent to the neighbor, no attempt
>> |                  should be made to verify its reachability.
>> |      DELAY       The neighbor is no longer known to be reachable, and
>> |                  traffic has recently been sent to the neighbor.
>> |                  Rather than probe the neighbor immediately, however,
>> |                  delay sending probes for a short while in order to
>> |                  give upper layer protocols a chance to provide
>> |                  reachability confirmation.
>>
>>
> 
> It is all depending on the meaning of the word "recently".
> You imply, that if timeouts have been triggered, then it is no longer "recent",
> but that is not the only interpretation, it is up to the implementer to decide
> what is "recently".

That quoted text is just a "brief" description.  The document has detailed
state machine.


> Therefore, if a timeout occurs due to no traffic, they must be probed before
> they are garbage collected.

It is what we do in PROBE state.


> If this is not acceptable, how do you propose to solve the problem that you cannot
> make remote units inaccessible for more than a fraction of a second?

How many neighbors do you want to maintain?
I guess you have to increase the number of gc_thresh1.

-- 
Hideaki Yoshifuji <hideaki.yoshifuji@miraclelinux.com>
Technical Division, MIRACLE LINUX CORPORATION