[PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
laforge at netfilter.org
Wed Sep 28 10:32:40 CEST 2005
On Wed, Sep 28, 2005 at 02:25:16AM +0200, Henrik Nordstrom wrote:
> >That could be special cased and done lockless, with the counting
> >done per CPU.
> It's also not very hard for iptables when verifying the table to
> conclude that there really isn't any "real" rules for a certain hook
The detection should be quite straight-forward, yes.
> Allowing you to have as many ip tables modules you like in the kernel,
> but only using the hooks where you have rules.
I totally agree, that from a current perspective, I think the concept of
just loading a module (that has usage count 0) having severe impact on
system performance is just wrong. But then, users are used to the
current behaviour for almost five years now. Every decent script and/or
piece of documentation should by now refer to the fact that loading a
module implicitly registers it at the hooks, and that you only load
those modules that you really need.
In an ideal world, you would load iptables, and userspace would
configure a couple of chains, and then explicitly attach those chains to
the netfilter hooks.
Therefore: Let's do this right next time, but live with that fact for
> Drawback is that you loose the packet counters on the policy.
That's the big problem. People rely on that fact, because they're used
to it. If we introduce some new tool, or something that somehow works
differently, I don't have a change. But silently changing the semantics
with a kernel upgrade is not something that I'm willing to do on
Just imagine all those poor sysadmins who know nothing about current
kernel development, and who upgrade their kernel because their
distributor provides a new one - suddenly their accounting (which might
be relevant for their business) doesn't work anymore :(
> Exception: iptable_nat. Needs the hooks for other purposes as well,
> not just the iptable so here the hooks can not be deactivated when
> there is no rules.
yes, even though we could make the ip_nat / iptable_nat split (that is
introduced in 2.6.14) in a way that would make ip_nat.ko register those
hooks that are implicitly needed, and iptable_nat only the user-visible
- Harald Welte <laforge at netfilter.org> http://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20050928/14d8b742/attachment.pgp
More information about the netfilter-devel