Hi,
On Tue, Jul 10, 2018 at 11:22:36PM +0900, Taehee Yoo wrote:
> In order to restrict element number of each set, member ->size is used.
> that used to be given by user-space. if user-space don't specify ->size,
> number of element is unlimited. so that overflow can occurred.
>
> After this patch,
> If user-space don't specify ->size, 65535 is set.
> all types of set have same default size.
>
> test commands:
> %nft add table ip aa
> %nft add map ip aa map1 { type ipv4_add : verdict\; }
> %nft list ruleset
>
> Before this patch:
> table ip aa {
> map map1 {
> type ipv4_addr : verdict
> }
> }
>
> After this patch:
> table ip aa {
> map map1 {
> type ipv4_addr : verdict
> size 65535
> }
> }
>
> V2:
> - Add default set->size value instead add check set->size routine.
> - Requested by Florian Westphal
I agree with Florian in that we can simplify the code by always doing
size accounting all over the place (I mean remove branches to do
inconditional size accounting). So we do size accounting even if we
don't need it.
Then, moving forward, if we go for default size for sets, we may need
a way to signal the kernel that the hashtable is resizable, in case
the user wants to dynamically update the maximum size (in such case,
the rhashtable implementation would be still useful I think).
Another possibility is that we can get rid of the rhashtable, and
implement a more simple way to resize the existing fixed size
hashtable, given that this will only happen from control plane and it
should be a rare operation (just like conntrack resizing), but
probably we may be re-inventing the wheel.
Thoughts?
In any case, this patch should go nf-next, so we have time to discuss
things, so this series are applied, except this one ;-).
Thanks!
--
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
