On 24.02, Josh Hunt wrote: > On 02/24/2015 04:42 AM, Patrick McHardy wrote: > >On 24.02, Daniel Borkmann wrote: > >> > >>Simplest fix would be, similarly as in other users: > >> > >>diff --git a/net/netfilter/nft_hash.c b/net/netfilter/nft_hash.c > >>index 61e6c40..47abdca 100644 > >>--- a/net/netfilter/nft_hash.c > >>+++ b/net/netfilter/nft_hash.c > >>@@ -192,6 +192,7 @@ static int nft_hash_init(const struct nft_set *set, > >> .key_offset = offsetof(struct nft_hash_elem, key), > >> .key_len = set->klen, > >> .hashfn = jhash, > >>+ .max_shift = 20, /* 1M */ > >> .grow_decision = rht_grow_above_75, > >> .shrink_decision = rht_shrink_below_30, > >> }; > >> > >>But I presume Josh wanted to resend his code ... or wait for nft > >>folks to further review? > > > >We're perfectly fine with that patch, although I'd say lets use a > >slightly larger value (24) to cover what we know people are doing > >using ipset. > > I just sent a patch similar to Daniel's in the set 'nft hash resize fixes' > using a max_shift value of 24. I still think this value should be tunable, > but sent the patch to fix the immediate expansion problem for now. Thanks. I actually don't think we should require that parameter at all, any limits shouldn't be imposed by the data structure but by the code using it. We're perfectly fine using the available memory as a limit if the users wants this, provided that hash expansion succeeds and the lookups stay fast. But for now let's just fix the immediate problem, I agree. -- 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
