Re: [PATCHv6 0/3] Interface group patches

[Patrick McHardy <kaber@trash.net>]

David Miller wrote:
> From: Laszlo Attila Toth <panther@balabit.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.