In article [ref] (at Sat, 25 Sep 2004 00:56:23 -0700), "David S. Miller" [off-list ref] says:

So let's discuss #4.  It is the first idea I had to combat the
"problem", but honestly right now I am beginning to think that
the real solution is to simply remove the INCOMPLETE checks
altogether.

Neighbours are a sub-cache of the routing cache.  Therefore when
a neigh entry has a singular refcount, no routing cache entry
points to it.  No routing cache entry, we're not sending packets
to that neighbour any time soon, so there is no reason (especially
during strong pressure) to hold onto such entries.

First, in IPv6, we usually do not create cache entries for now.
(I assume it is rt6_info with RTF_CACHE flag set.)
We create one if we receives
 - redirect
or
 - too big (for pmtu).

Personally, I agree to change this; always to create routing cache.

Second, we should free only STALE entries first for specification
conformity; lifetime of stale entries is not standardized,
but ones of others are.
We will be broken especially for neighbour-cache reachable-time is
longer than routing-cache lifetime) case.

So, I would say
 - stage 1: if num_entries > low_thresh,
             try purge STALE entries (with refcnt == 1).
             if not enough, schedule flushing routing cache.
 - stage 2: if num_entries > high_thresh,
             try to purge all states (except for permanent entries, 
             but including 1 second-old INCOMPLETE entries.)
             if not enough, schedule flushing routing cache.
 - stage 3: if num_entries > ultimate_thresh, we fail.
or something.

So, I cannot agree simiply removing the "INCOMPLETE" test.

-- 
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA