Bug 2173801

Creating 35000 tables in one go (much quicker than individual calls) like so:

for ((i=0;i<35000;i++)); do echo "add table inet t$i"; done | nft -f -

takes 27s and the running nft command uses 17.2GB of RES memory at most.

Listing is a tad more expensive, 'nft list ruleset' eats at most 17.4GB RES
memory.

These numbers are identical with nft from RHEL9.2 and upstream.

Trying to compare this against iptables-nft:

# time ((echo '*filter'; for ((i=0;i<35000;i++)); do echo ":c$i - [0:0]"; done; echo 'COMMIT') | iptables-restore)

real	0m0.280s
user	0m0.261s
sys	0m0.116s

# iptables-save | wc -l
35007

# time iptables-save >/dev/null

real	0m0.176s
user	0m0.067s
sys	0m0.108s

# time iptables -X

real	0m0.171s
user	0m0.033s
sys	0m0.132s

The comparison is unfair though since we can't add tables with iptables (the
few it uses are added implicitly if needed). So adjust the nftables testcase to
only create chains:

# time (for ((i=0;i<35000;i++)); do echo "add chain ip filter c$i"; done | nft -f -)

real	0m0.319s
user	0m0.266s
sys	0m0.107s

# time nft list ruleset | wc -l
105001

real	0m0.173s
user	0m0.070s
sys	0m0.204s

# time nft flush ruleset

real	0m0.013s
user	0m0.001s
sys	0m0.011s

These numbers are much better. This is because nft assumes few tables,
therefore each table object is rather fat in user space. Also when adding a
chain, it fetches all tables from the kernel. This is why adding a chain with
many tables present is slow.

Fixing the latter is a pretty simple change, though adding an excessive amount
of tables is really uncommon and I don't expect this to happen outside of a
crafted test case.

Closing this for now as there is no memory leak but adding 35k tables is merely
unexpectedly heavy. Feel free to reopen in case you have a valid use-case for a
significant amount of tables. Upstream didn't optimize for that case because it
doesn't know of any.