From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@vger.kernel.org, josh@joshtriplett.org,
paulmck@linux.vnet.ibm.com
Subject: Re: [PATCH v3] netfilter: nft_hash: bug fixes and resizing
Date: Fri, 7 Mar 2014 11:49:02 +0100 [thread overview]
Message-ID: <20140307104902.GA12188@localhost> (raw)
In-Reply-To: <1393946511-28174-1-git-send-email-kaber@trash.net>
On Tue, Mar 04, 2014 at 04:21:51PM +0100, Patrick McHardy wrote:
> The hash set type is very broken and was never meant to be merged in this
> state. Missing RCU synchronization on element removal, leaking chain
> refcounts when used as a verdict map, races during lookups, a fixed table
> size are probably just some of the problems. Luckily it is currently
> never chosen by the kernel when the rbtree type is also available.
>
> Rewrite it to be usable.
>
> The new implementation supports automatic hash table resizing using RCU,
> based on Paul McKenney's and Josh Triplett's algorithm "Optimized Resizing
> For RCU-Protected Hash Tables" described in [1].
>
> Resizing doesn't require a second list head in the elements, it works by
> chosing a hash function that remaps elements to a predictable set of buckets,
> only resizing by integral factors and
>
> - during expansion: linking new buckets to the old bucket that contains
> elements for any of the new buckets, thereby creating imprecise chains,
> then incrementally seperating the elements until the new buckets only
> contain elements that hash directly to them.
>
> - during shrinking: linking the hash chains of all old buckets that hash
> to the same new bucket to form a single chain.
>
> Expansion requires at most the number of elements in the longest hash chain
> grace periods, shrinking requires a single grace period.
>
> Due to the requirement of having hash chains/elements linked to multiple
> buckets during resizing, homemade single linked lists are used instead of
> the existing list helpers, that don't support this in a clean fashion.
> As a side effect, the amount of memory required per element is reduced by
> one pointer.
>
> Expansion is triggered when the load factors exceeds 75%, shrinking when
> the load factor goes below 30%. Both operations are allowed to fail and
> will be retried on the next insertion or removal if their respective
> conditions still hold.
Applied, thanks Patrick.
prev parent reply other threads:[~2014-03-07 10:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 15:21 [PATCH v3] netfilter: nft_hash: bug fixes and resizing Patrick McHardy
2014-03-07 10:49 ` Pablo Neira Ayuso [this message]
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=20140307104902.GA12188@localhost \
--to=pablo@netfilter.org \
--cc=josh@joshtriplett.org \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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.