tsumi
May 31, 2026, 1:30pm
1
Hi everyone,
(sorry for censored links, looks like I’m not authorized to post them (?))
this post is related to this firewalld bug:
main ← andrewlukoshko:fix/nftables-batch-ipset-elements
opened 12:31PM - 10 Mar 26 UTC
## Summary
`set_restore()` currently creates one `{"add": {"element": ...}}` nf… t operation per ipset entry, then sends them in chunks of 1000 to `set_rules()` via `GLib.idle_add`. On older nftables/kernel combinations (e.g. nftables 1.0.4 / kernel 4.18 shipped in RHEL/AlmaLinux 8), each incremental element insertion into an interval set has O(n) cost proportional to the current set size, making the overall complexity O(n²).
With 12,000 ipset entries this causes `firewall-cmd --reload` to take **~80 seconds** on RHEL 8 with the nftables backend. Even on newer systems (nftables 1.0.9 / kernel 5.14), batching yields a ~20% improvement.
This patch accumulates all element fragments and sends batched `"add element"` operations — one per chunk of 1000 elements — instead of one per entry. This reduces nft operations from N to ceil(N/1000), letting nftables handle bulk element insertion efficiently.
## Benchmark (12k ipset entries, nftables backend)
| | Before | After |
|---|---:|---:|
| RHEL/AL 8 (nftables 1.0.4, kernel 4.18) | ~82,600 ms | ~2,600 ms |
| RHEL/AL 9 (nftables 1.0.9, kernel 5.14) | ~1,560 ms | ~1,240 ms |
## Root cause detail
Profiling `json_cmd` calls inside `set_restore()` showed each successive chunk taking progressively longer on RHEL 8:
```
Chunk 1 (1000 entries): 0.29s
Chunk 6 (1000 entries): 4.70s
Chunk 12 (1000 entries): 15.71s
Total: 80.54s
```
The raw libnftables API on the same machine can add all 12k elements in 0.14s when done in a single batch, confirming the bottleneck is incremental per-element insertion, not the nftables library itself.
Fixes #933
## Test plan
- Tested on AlmaLinux 8.10 (nftables 1.0.4, kernel 4.18) and AlmaLinux 9.7 (nftables 1.0.9, kernel 5.14) with 12,000 random /24 ipset entries
- Verified all entries load correctly after reload via `firewall-cmd --ipset=<name> --get-entries` and `nft list set`
- Verified empty ipsets and small ipsets (100 entries) work correctly
That cause a large reload time issue with large ipsets (>10-20k networks).
The fix was published in test on March 2026 on Almalinux (I was not able to find a similar test package for Rocky) AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
Today I noticed that an update for firewalld was released for Rocky 8 too:
firewalld 0.9.11-11.el8_10
But it doesn’t appear to address this bug: Rocky Linux 8 x86_64 BaseOS
Someone has infos about this bugfix or where it is tracked?
I searched everywhere but I wasn’t able to locate anything related for Rocky 8 (maybe the large use of Anubis to contain of AI bots flooding degraded the google search too…)
Thanks
Due to spammers, new users can post links to rockylinux domains only. I fixed the links in your post. Once your reputation level increases after you have posted a bit, then you will be able to do more.
BTW, the fix was pushed in Almalinux testing repo, so it’s not an official fix from RHEL Rocky aims to be 1:1 with RHEL so if RHEL haven’t applied that fix, then that will be why Rocky doesn’t have it. Almalinux is ABI-compatible, so they are not 100% the same as RHEL. Once you’ve understood that difference, then you will know why Rocky doesn’t have it. So, if Red Hat add it to RHEL, then Rocky will have it.