[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150116155835.GA15052@casper.infradead.org>
Date: Fri, 16 Jan 2015 15:58:35 +0000
From: Thomas Graf <tgraf@...g.ch>
To: Patrick McHardy <kaber@...sh.net>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
kernel@...r.kernel.org, herbert@...dor.apana.org.au,
paulmck@...ux.vnet.ibm.com, edumazet@...gle.com,
john.r.fastabend@...el.com, josh@...htriplett.org,
netfilter-devel@...r.kernel.org
Subject: Re: [PATCH 7/9] rhashtable: Per bucket locks & deferred
expansion/shrinking
On 01/16/15 at 03:34pm, Patrick McHardy wrote:
> On 15.12, Thomas Graf wrote:
> > In the event of an expansion or shrinking, the new bucket table allocated
> > is exposed as a so called future table as soon as the resize process
> > starts. Lookups, deletions, and insertions will briefly use both tables.
> > The future table becomes the main table after an RCU grace period and
> > initial linking of the old to the new table was performed. Optimization
> > of the chains to make use of the new number of buckets follows only the
> > new table is in use.
>
> AFAICT nft_hash_walk() will miss new entries during this period.
> Am I missing anything here?
A walker may not see insertions that occur after the walker was started
if resizing is enabled. Is that a problem for nftables?
--
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