From mboxrd@z Thu Jan  1 00:00:00 1970
From: "David S. Miller" <davem@davemloft.net>
Subject: Re: [6/6]: jenkins hash for neigh
Date: Sat, 25 Sep 2004 17:48:02 -0700
Sender: netdev-bounce@oss.sgi.com
Message-ID: <20040925174802.43c86665.davem@davemloft.net>
References: <20040923225158.23c2d502.davem@davemloft.net>
	<20040924085234.GE3236@sunbeam.de.gnumonks.org>
	<20040924142702.62a2b23d.davem@davemloft.net>
	<20040925064406.GL3236@sunbeam.de.gnumonks.org>
	<20040925005623.2faf8faf.davem@davemloft.net>
	<20040925090933.GU3236@sunbeam.de.gnumonks.org>
	<20040925133342.GA11292@souterrain.chygwyn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: laforge@gnumonks.org, netdev@oss.sgi.com
Return-path: <netdev-bounce@oss.sgi.com>
To: Steven Whitehouse <steve@chygwyn.com>
In-Reply-To: <20040925133342.GA11292@souterrain.chygwyn.com>
Errors-to: netdev-bounce@oss.sgi.com
List-Id: netdev.vger.kernel.org

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