On Thu, 15 May 2008, Thomas Jacob wrote:
On Thu, 2008-05-15 at 13:18 +0200, Jan Engelhardt wrote:
On Thursday 2008-05-15 12:57, Anton wrote:
Definitelly what my test shows - while rule-inserts - if you
try to insert 10000 rules - after a several hundreds - it
will be inserting like a 1 rule in 1 second and slowness
will progress :)
Your insertion slowness is probably due to incorrect use of iptables.
What do you mean by that? Isn't it a fact, that the iptables command
utility and to a lesser extent also iptables-restore is pretty slow in
updating the ruleset when you have a large number of rules, simply
because it copies the entire ruleset to userspace, modifies it there,
and then copies the resulting rule set back to the kernel?
Yes, its true that iptables is slow with large rule sets (even when using
iptables-restore). It does copy the entire ruleset everytime, but the
copy process (between userspace and kernel) is not the slow part, its the
parsing the ruleset (libiptc).
I have fixed some of the ruleset parsing issues in libiptc. (50k chains
ruleset listing reduced from 5 minuts to 0.5 sec).
(Already accepted in latest SVN/git:)
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=commit;h=73ff92a2b0f338374a1f9830009d38b1f0ccaf42
There are still some libiptc scalability issues left... That I promised
Patrick I would solve... Lets hope I'll fix them before the workshop ;-)
If doing a lot of rule changes, you should definitly use iptables-restore
or CPAN perl module IPTables::libiptc.
Hilsen
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
