[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090901092317.0fe6c9f2@nehalam>
Date: Tue, 1 Sep 2009 09:23:17 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Octavian Purdila <opurdila@...acom.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Lucian Adrian Grijincu <lgrijincu@...acom.com>,
netdev@...r.kernel.org
Subject: Re: neighbour table RCU
On Tue, 1 Sep 2009 18:55:34 +0300
Octavian Purdila <opurdila@...acom.com> wrote:
> On Tuesday 01 September 2009 09:50:17 Eric Dumazet wrote:
> > Stephen Hemminger a écrit :
> > > Looking at the neighbour table, it should be possible to get
> > > rid of the two reader/writer locks. The hash table lock is pretty
> > > amenable to RCU, but the dynamic resizing makes it non-trivial.
> > > Thinking of using a combination of RCU and sequence counts so that the
> > > reader would just rescan if resize was in progress.
> >
> > I am not sure neigh_tbl_lock rwlock should be changed, I did not
> > see any contention on it.
> >
>
> Speaking about neighbour optimizations, here is a RFC patch which makes the
> tables double linked, for constant time deletion. It has given us a significant
> performance improvement - in less then usual setups though, with lots of
> neighbours.
>
> Would something like this be acceptable for upstream? (pardon the p4 diff dump
> :) - but I think it will give a rough idea, if acceptable will clean it up and
> properly submit it)
>
> BTW, would switching to list_head be better?
Use hlist for the neighbour table. It has the right properties
and makes future RCU easier.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists