Re: [PATCH 7/9] rhashtable: Per bucket locks & deferred expansion/shrinking

[Thomas Graf <tgraf@suug.ch>]

On 01/16/15 at 10:07pm, Patrick McHardy wrote:
> I'm afraid that's not good enough. The resize operation is deferred,
> so even if userspace does not perform an operation after starting
> the dump, the hash might change.
> 
> We can obviously work around that by incrementing a generation
> counter in rhashtable. The main problem I see is that with something
> very actively changing the ruleset, we might never complete a dump.

Right, I suggest adding a function pointer to rhashtable_params,
which when set, is called on resize so users can bump their own
sequence counter on resize.

> Dumps are usually rare, I think its preferrable to defer rehashing.

Resize operations should be *really* rare as well unless you start
with really small hash table sizes and constantly add/remove at the
watermark.

Re-dumping on insert/remove is a different story of course. Do you
care about missed insert/removals for dumps? If not we can do the
sequence number consistency checking for resizing only.