[iptables PATCH 0/3] Speed up restoring huge rulesets

[Phil Sutter <phil@nwl.cc>]

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