OpenShift tends to create huge rulesets[*] and consequently wonders why
iptables is slow. Anyway, iptables-nft-save really does odd things:
* For each jump target, it checks if such extension exists, despite
already knowing whether the target is a chain or not. This is solved
in patch 2, with patch 1 preparing nft_parse_immediate() to make the
change simpler.
* Every l4proto match causes a call to getprotobynumber() which in turn
opens /etc/protocols. One could cache the lookups, but preferring the
builtin fallback list of protocol names and numbers is much simpler.
Do that in patch 3, aligning said list with /etc/protocols to not
change output unexpectedly.
[*] I have a "real-life" dump adding 50k chains and 130k rules. Dumping
it to /dev/null took 45s on my testing VM, with these patches
applied I'm down to 2.7s.
The last patch is fallout from the above, simplifying family ops
callbacks a bit given that there is only a single *tables_command_state
struct left.
Phil Sutter (4):
nft: Simplify immediate parsing
nft: Speed up immediate parsing
xshared: Prefer xtables_chain_protos lookup over getprotoent
nft: Don't pass command state opaque to family ops callbacks
iptables/nft-arp.c | 32 ++++++------------
iptables/nft-bridge.c | 55 +++++++++++++------------------
iptables/nft-ipv4.c | 40 ++++++++---------------
iptables/nft-ipv6.c | 40 ++++++++---------------
iptables/nft-shared.c | 75 ++++++++++++++++++++-----------------------
iptables/nft-shared.h | 35 ++++++++++----------
iptables/nft.c | 4 +--
iptables/nft.h | 2 +-
iptables/xshared.c | 8 ++---
libxtables/xtables.c | 19 ++++-------
10 files changed, 126 insertions(+), 184 deletions(-)
--
2.34.1
