Re: [6/6]: jenkins hash for neigh

["David S. Miller" <davem@davemloft.net>]

On Mon, 27 Sep 2004 11:29:33 +0200
Harald Welte <laforge@gnumonks.org> wrote:

> > > 4) The controversial/RFC patch, dorking with neigh_forced_gc()
> 
> It performed perfectly, I wasn't able to reproduce those overflows
> anymore (testing with two /16 networks and about 200kpps incoming
> packets to unresolved and non-existant neighbours)
> 
> > I'll do tests with and without INCOMPLETE check. No results until late
> > Sunday/Monday, as indicated above.
> 
> I didn't even bother doing the INCOMPLETE check since Yoshifuji
> indicated that this caused problems with IPv6....

You might as well have.  Effectively, due to a bug that Herbert Xu
spotted, diff4 acts the same as if the INCOMPLETE checks were
removed.  The time_after() check for INCOMPLETE entries in the
diff4 changes ended up being opposite of what it should be.

Yoshifuji said:

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

What some standard says is meaningless in these sorts
of situations.  It lacks any sense.  If we are reaching
limits of caches and we need to create a new neighbour entry
in order to communicate with another hosts we must purge
anything we can.  I challenge something like TAHI to even
be able to check out a case like this and for the results to
be meaningful in some way.  They certainly won't be.

So I'm going to remove the INCOMPLETE tests instead of my
original diff4 since:

1) That is effectively what my buggy diff4 was doing anyways.
2) It is the simplest change and keeps us from having to scan
   the hash table twice under high load situations when we need
   the cycles very badly.

Yoshifuji, if we drop neighbour entry, we will just reprobe for
this neighbour if we should try to communicate with it again.
It is not the end of the world.