David Miller wrote:
From: Laszlo Attila Toth <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
