Scalability performance work on iptables/libiptc
Status from this message: Applied, thanks a lot.
Get series with b4
b4 am [email protected]Versions newest first
Patches in v1 Applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | iptables/libiptc perf issue: Sorting chain during pull-outlibiptc/ | +3 | 1 reply | |
| 2/2 | iptables/libiptc perf issue: Finding jump chains is suboptimallibiptc/ | +19 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] Scalability performance work on iptables/libiptc
There are scalability/performance issues with iptables in libiptc.c, when parsing/pulling-out the ruleset blob. As I discussed shortly with Harald and Martin during the workshop.
These patches performance optimize two scalability issues.
1) Sorting chain during pull-out give worst-case runtime O(Chains^2), reduced to O(Chains) only when creating a new chain.
2) Finding jump chains is suboptimal O(Chain*Rules), reduced to O(R) and chain offset lookup to O(1).
The idea behind these fixes are based upon patches posted by Paul C. Diem <[email protected]> back in June+Oct 2006.
These performance issues will only be noticed when the rule set is large enough. For me, in real life, its actually a real performance issue. On one production system (Rules=26209 and Chains=6233) it takes 10 seconds to create a new chain by calling "iptables -N test", with these patches its reduced to 0.145 second.
Signature · 7 lines
Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer