On Tue, Apr 03, 2018 at 11:15:39PM +0200, Phil Sutter wrote:
> Drop nft_set_type's ability to act as a container of multiple backend
> implementations it chooses from. Instead consolidate the whole selection
> logic in nft_select_set_ops() and the actual backend provided estimate()
> callback.
>
> This turns nf_tables_set_types into a list containing all available
> backends which is traversed when selecting one matching userspace
> requested criteria.
>
> Also, this change allows to embed nft_set_ops structure into
> nft_set_type and pull flags field into the latter as it's only used
> during selection phase.
>
> A crucial part of this change is to make sure the new layout respects
> hash backend constraints formerly enforced by nft_hash_select_ops()
> function: This is achieved by introduction of a specific estimate()
> callback for nft_hash_fast_ops which returns false for key lengths != 4.
> In turn, nft_hash_estimate() is changed to return false for key lengths
> == 4 so it won't be chosen by accident. Also, both callbacks must return
> false for unbounded sets as their size estimate depends on a known
> maximum element count.
>
> Note that this patch partially reverts commit 4f2921ca21b71 ("netfilter:
> nf_tables: meter: pick a set backend that supports updates") by making
> nft_set_ops_candidate() not explicitly look for an update callback but
> make NFT_SET_EVAL a regular backend feature flag which is checked along
> with the others. This way all feature requirements are checked in one
> go.
Applied, thanks Phil.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
