[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150116160354.GI30132@acer.localdomain>
Date: Fri, 16 Jan 2015 16:03:55 +0000
From: Patrick McHardy <kaber@...sh.net>
To: Thomas Graf <tgraf@...g.ch>
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 16.01, Thomas Graf wrote:
> 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?
No, that would be Ok. The case I'm wondering about is:
- insertion
- resize starts
- another insertion
- walker, resize not finished yet
--
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