[lkml]   [2005]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
    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
    chain-related hooks.

    - Harald Welte <>
    "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
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-09-28 10:36    [W:0.026 / U:0.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site