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

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

On Sat, 25 Sep 2004 14:33:42 +0100
Steven Whitehouse <steve@chygwyn.com> wrote:

> On Sat, Sep 25, 2004 at 11:09:33AM +0200, Harald Welte wrote:
> > On Sat, Sep 25, 2004 at 12:56:23AM -0700, David S. Miller wrote:
> > > 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.
> > 
> > I am sure this is valid for IPv4 and IPv6.  How about other users of the
> > neighbour cache, do they share this assumption?  I have to admit that I
> > never looked throgh the ATM or 
> >
> I cannot see this being any problem for DECnet at all.... the entry you
> most want to hold on to is the entry for the default router of which
> there will be a max of one per interface. This applies only in end node
> mode and we hold a ref count to it anyway, so that it should have the
> same effect as the routing cache entry holding a ref,

And ATM clip is for ipv4's routing layer too so...