From: Stephen Hemminger <shemminger@vyatta.com>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Lucian Adrian Grijincu <lgrijincu@ixiacom.com>,
netdev@vger.kernel.org
Subject: Re: neighbour table RCU
Date: Tue, 1 Sep 2009 09:23:17 -0700 [thread overview]
Message-ID: <20090901092317.0fe6c9f2@nehalam> (raw)
In-Reply-To: <200909011855.34175.opurdila@ixiacom.com>
On Tue, 1 Sep 2009 18:55:34 +0300
Octavian Purdila <opurdila@ixiacom.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.
next prev parent reply other threads:[~2009-09-01 16:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 22:04 neighbour table RCU Stephen Hemminger
2009-09-01 6:50 ` Eric Dumazet
2009-09-01 15:55 ` Octavian Purdila
2009-09-01 16:14 ` Eric Dumazet
2009-09-01 16:56 ` Octavian Purdila
2009-09-01 16:23 ` Stephen Hemminger [this message]
2009-09-01 15:59 ` Stephen Hemminger
2009-09-01 16:13 ` Eric Dumazet
2009-09-01 21:24 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090901092317.0fe6c9f2@nehalam \
--to=shemminger@vyatta.com \
--cc=eric.dumazet@gmail.com \
--cc=lgrijincu@ixiacom.com \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.