2018-07-19 1:44 GMT+09:00 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>:
> 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.
>
Thank you for reviewing!
> 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).
>
In my opinion, we can use estimate callback.
If user sets 'performance', hashtable will be selected
or 'memory' is set, rhashtable will be selected.
As far as I know, updating flags and size value is not support.
If we are going to add to support updating maximum size
manually or dynamically, new flags should be added.
> 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?
>
I would like to keep using rhashtable unless the rhashtable
reduces lookup performance much. because I think rhashtable is
a little bit easy to use and it makes readable code.
> 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!
I agree with it, I checked!
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
