Hi! As we all know, loading a big ruleset can be quite slow, even when using iptables-restore. Back in June last year I added some improvements to libiptc, providing about 40% speedup when loading my artificial 1000-chain 10000-rule ruleset. However, there were still a couple of algorithms with too high computational complexity left in libiptc. They could not be eliminated without a complete rewrite. During the last week, I did that [painful, and probably still quite buggy] complete rewrite - it has just been commited to CVS. Let the numbers speak for themselves: Loading a ruleset with 1000 chains, each 10 rules with iptables-restore on an Intel P3-733: original code (iptables-1.2.8) 3m55.575s (3m27.310s/0m28.270s) modified libiptc with relative offset + correct_cache() (iptables-1.2.9) 2m19.566s (1m52.510s/0m26.980s) new rewritten libiptc2 (upcoming iptables-1.3.0) 0m1.255s (0m1.205s/0m0.048s) If you want to thank me for this speedup: Please do so by finding and debugging the remaining issues: TODO: - implement TC_DELETE_ENTRY (should be fairly trivial) - fix all the debugging/checking/dumping macros that I have disabled - fix a race condition with rule_iterator_cur (already fixed with chain_iterator_cur, easy) - find out why 'iptables -X' doesn't work yet - verify that counter mapping really works in all obscure cases - more testing - find a theory why the system time decreased when modifications happened only in userspace code.. and getsockopt/setsockopt is still called the same way - consume less memory: release (*handle)->entries after parsing Thanks! -- - Harald Welte <laforge@xxxxxxxxxxxxx> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie
Attachment:
signature.asc
Description: Digital signature
