Message-ID: <alpine.DEB.1.10.0904111751430.28893@asgard.lang.hm>
Date:	Sat, 11 Apr 2009 17:54:41 -0700 (PDT)
From:	david@...g.hm
To:	Kyle Moffett <kyle@...fetthome.net>
cc:	David Miller <davem@...emloft.net>, jengelh@...ozas.de,
	paulmck@...ux.vnet.ibm.com, torvalds@...ux-foundation.org,
	mingo@...e.hu, laijs@...fujitsu.com, shemminger@...tta.com,
	jeff.chua.linux@...il.com, dada1@...mosbay.com, kaber@...sh.net,
	r000n@...0n.net, linux-kernel@...r.kernel.org,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: iptables very slow after commit
 784544739a25c30637397ace5489eeb6e15d7d49

On Sat, 11 Apr 2009, Kyle Moffett wrote:

> On Sat, Apr 11, 2009 at 2:00 AM, David Miller <davem@...emloft.net> wrote:
>> From: Jan Engelhardt <jengelh@...ozas.de>
>> Date: Sat, 11 Apr 2009 07:14:50 +0200 (CEST)
>>
>>> The fact that `iptables -A` is called a hundred times means you are
>>> doing 100 table replacements -- instead of one. And calling
>>> synchronize_net at least a 100 times.
>>>
>>> "Wanna use iptables-restore?"
>>
>> I want to derail this line of thinking as fast as possible.
>>
>> This is not an acceptable response to this problem.  We made something
>> fundamentally slower by several orders of magnitude.
>>
>> Therefore, saying "Don't insert your firewall rules like that." is not
>> a valid response for this regression.
>>
>> We really have to fix it or revert.
>
> Let me start by saying that I agree that for most systems this patch
> provided a bad performance tradeoff that needs to get fixed.
>
> On the other hand I have certain systems where I would much rather
> reduce the per-packet load by a few percent...  even if it increases
> the effort to load a new ruleset by many orders of magnitude!!!  Quite
> simply the boxes only reboot a few times a year but in-between times
> they forward many terabytes of low-latency network traffic.
>
> So... to play devils advocate:
>
> Almost all of the standard firewall tools (such as shorewall, etc) are
> already using iptables-restore command to load firewall rules,
> primarily because using separate iptables commands was *already* way
> too slow.  There's also the serious race-condition of doing a firewall
> restart that way where you only have half your rules loaded for a bit.
> The "iptables" command is fine for fiddling around with the command
> line and making minor tweaks, but it simply doesn't cut it for
> large-scale rules.

what are the userspace level tools that I am supposed to use in place of 
my current process? (which is to have a script that 1. stops traffic, 2. 
executes the iptables commands to create the rules that I want, then 3. 
enables traffic)

iptables-restore only works if you are actually restoring the old set of 
rules. if you need to change the rules that doesn't work.

David Lang

> I remember when switching from a shell-based shorewall to a perl-based
> shorewall.  The time to build my rule lists with the perl-based
> version was about 20% of what it had been, but the time to load the
> rules into the kernel with iptables-restore was easily 2% or perhaps
> less.
>
> Finally, if you really are loading a couple hundred IPs into a linear
> ruleset, you're adding a fair amount of packet latency to each and
> every packet that goes through totally independent of iptables load
> time.  It would be much better to use ipsets (or similar) because they
> load all of the IP ranges into an appropriate tree datastructure with
> O(small-constant * log(N) + large-constant * 1) lookup instead of
> O(large-constant * N).
>
> Cheers,
> Kyle Moffett
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Powered by blists - more mailing lists