The largest penalty when restoring a large ruleset is checking for whether a given target name is a chain or extension. Patch 2 adds a cache to libxtables for failed extension lookups so consecutive ones (e.g. multiple rules jumping to the same chain) are fast. If a ruleset contains many user-defined chains, there is still a significant slow-down due to the single extension lookup which remains. Patch 3 introduces an announcement mechanism, implying that a chain line in a dump file is never a target. Testing my OCP ruleset (50k chains, 130k rules, 90k chain jumps) again: variant before after ------------------------------------- legacy 1m31s 2.6s nft 1m47s 13s The performance gain is large enough to justify the lost warning if a chain name clashes with a non-standard target. The only case which was forbidden before, namely a clash with standard target (DROP, ACCEPT, etc.) is still caught due to patch 1 of this series. Changes since RFC: - Introduce patch 1 to catch the only real issue - Slight performance drop with nft due to the kept standard target check - Update commit messages Phil Sutter (3): nft: Reject standard targets as chain names when restoring libxtables: Implement notargets hash table libxtables: Boost rule target checks by announcing chain names include/xtables.h | 3 ++ iptables/iptables-restore.c | 1 + iptables/xshared.c | 4 +- iptables/xshared.h | 2 +- iptables/xtables-restore.c | 6 +-- libxtables/xtables.c | 81 +++++++++++++++++++++++++++++++++++++ 6 files changed, 90 insertions(+), 7 deletions(-) -- 2.34.1
