[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47437B12.9090009@trash.net>
Date: Wed, 21 Nov 2007 01:25:54 +0100
From: Patrick McHardy <kaber@...sh.net>
To: David Miller <davem@...emloft.net>
CC: panther@...abit.hu, jengelh@...putergmbh.de,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCHv6 0/3] Interface group patches
David Miller wrote:
> From: Laszlo Attila Toth <panther@...abit.hu>
> Date: Tue, 20 Nov 2007 14:52:12 +0100
>
>> Jan Engelhardt írta:
>>> On Nov 20 2007 14:14, Laszlo Attila Toth wrote:
>>>> This is the 6th version of our interface group patches.
>>>>
>>>> The interface group value can be used to manage different interfaces
>>>> at the same time such as in netfilter/iptables.
>>> I take it you could not use...?
>>> iptables -i iif1 -j dosomething
>>> iptables -i iif2 -j dosomething
>> This kind of usage requires static interface names. But there are
>> dynamic interfaces such as ppp, where the actual name is not always
>> known or sometimes they exist sometimes not. It is difficult to use
>> iptables this way, and every ifup/ifdown requires change in the iptables
>> ruleset (donwload it, modify and upload to the kernel). It may be too slow.
>
> This is actually not true these days.
>
> When network devices are created user events are generated and the
> user can rename the device however they like using a mapping table of
> any kind.
>
> And at such point the problem you present doesn't actually exist, you
> can know what the device will be named.
>
> And if rule loading dynamically is slow, we should fix that instead of
> creating infrastructure and interfaces we don't actually need.
I actually like this feature. Matching on names in iptables
has always been one of the major bottlenecks, taking
(according to my last measurement, which is some time ago)
about 1-2% of the total performance. This is of course in
large parts because the interface match is present on *every*
rule, but still some way to logically group interfaces seems
useful to me, not only for iptables, but also for routing rules,
traffic classifiers, af_packet sockets etc.
I'm working on the incremental ruleset changing API BTW :)
One of the changes will be that interface matching is not
a default part of every rule, and without wildcards it will
use the ifindex. But since the cost of this feature seems
pretty low, I don't see a compelling reason against it.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists