Hi Pablo,
On Thu, 1 Feb 2024, at 9:41 AM, Pablo Neira Ayuso wrote:
> On Wed, Jan 31, 2024 at 10:14:41AM +0200, Anton wrote:
>> Hello, I've been experimenting with nftables sets for the purpose of
>> geoip blocking. Let's say I'd like to add ip blocks for multiple
>> countries to a blacklist or to a whitelist. Perhaps the most efficient
>> way to do that would be by combining all required ip blocks in one set
>> (for each family). However since country ip blocks are a moving
>> target, I would need to regularly refresh parts of that set. My idea
>> was to delete all ip addresses corresponding to an ip block from the
>> set and then add the updated ip block. The problem is, this is very
>> slow. While adding an ip block takes (in my VM) 0.09s, deleting all
>> ip's from that same block takes 14.5s.
>>
>> This is how I'm doing the deletion and the time measurement:
>> printf '%s\n' "delete element inet test testset { $(cat test.set) };"
>> | /usr/bin/time -f %es nft -f -
>>
>> (the test.set file stores a comma-separated list of subnets)
>>
>> Is there a more efficient way to do this? I could of course flush the
>> set and rebuild it every time I need to update some part of it, but I
>> thought I'd ask before deciding to implement that.
>
> It is possible to flush the set and fill up with content again:
>
> flush set inet test testset
> add element inet test testset { ... }
I figured that this approach was already on the cards ("I could of course flush the set and rebuild"), though it is possible that Anton wasn't aware that it can be done atomically.
As far I understand the original post, he is aggregating multiple country blocklists to form a single set - a blacklist or a whitelist, as it was put. That would explain his interest in deleting subsets to begin with. The flush/rebuild approach may well be faster but it would also require reading in all of the subsets again - even those that haven't changed. Perhaps not a big deal in the greater scheme of things but it does make me wonder whether there's room for improvement as far as deletions go. I might test this on the next occasion that I'm experimenting with set behaviour.
--
Kerin Millar
