Re: About matching (also was: Multiple Targets)

[Wang Jian <lark@linux.net.cn>]

Hi Patrick Schaaf,

Common subexpression aggregation should be the best way to go. But
before that is done, we should consider how to improve current scheme,
right? It is a short term vs. long term problem.

Although ! --previous can be done, I am against it with current scheme.
The current scheme is for line by line match, not for structured
semantic such as if-else. Structured rule matching semantic needs much
work for correctness of insertion or deletion.

The --previous is a speedup, it is by no means a structured change.

I will defend my idea of duplication mark. It does make sense. It keeps
user space compatibility very well.

Consider this

iptables -A SOMECHAIN -m this -m that -j ACTION1
iptables -A SOMECHAIN --previous -j ACTION2
iptables -A SOMECHAIN --previous -j RETURN

The user space doesn't do the real work. The kernel space code store the
rules like this:

iptables -A SOMECHAIN -m this -m that -j ACTION1
iptables -A SOMECHAIN -m this -m that -j ACTION2 (dup match)
iptables -A SOMECHAIN -m this -m that -j RETURN (dup match)

When user space do delete, it do deletion as old days. But kernel, do
the trivial magic.

If delete the first

iptables -A SOMECHAIN -m this -m that -j ACTION2 <-- de-mark
iptables -A SOMECHAIN -m this -m that -j RETURN (dup match)

If delete the second

iptables -A SOMECHAIN -m this -m that -j ACTION1
iptables -A SOMECHAIN -m this -m that -j RETURN (dup match)

Do --previous insertion 

iptables -A SOMECHAIN -m this -m that -j ACTION1
iptables -A SOMECHAIN -m this -m that -j NEWACTION1 (dup match)
iptables -A SOMECHAIN -m this -m that -j ACTION2 (dup match)
iptables -A SOMECHAIN -m this -m that -j RETURN (dup match)

Do non --previous insertion

iptables -A SOMECHAIN -m this -m that -j ACTION1
iptables -A SOMECHAIN -m newmatch -j NEWACTION1
iptables -A SOMECHAIN -m this -m that -j ACTION2 <-- de-mark
iptables -A SOMECHAIN -m this -m that -j RETURN (dup match)


On Wed, 13 Apr 2005 09:14:27 +0200, Patrick Schaaf <bof@bof.de> wrote:

> Hi Jozsef,
> 
> On Wed, Apr 13, 2005 at 09:03:14AM +0200, Jozsef Kadlecsik wrote:
> > On Wed, 13 Apr 2005, Patrick Schaaf wrote:
> > 
> > > Also see my other mail: I think that all this is too complicated and
> > > too restrictive on the admin of the machine, and should simply NOT
> > > be done. The "more interesting" problem above, seems to confirm
> > > this feeling :)
> > 
> > I absolutely agree.
> > 
> > Rule evaluation should be improved by replacing the current linear
> > algorithm with some tree-based solution like nf-hipac. Or even with a tree
> > of internal IP sets ;-)
> 
> Or with a code generator with proper common subexpression elimination.
> Wasn't there a tcng project going that way? I sometimes think that
> this must be the right approach, just because so much optimization
> work went into gcc - and it can't be too hard, at least on current
> server/desktop processors, when even a full kernel compile is only
> one or two minutes...
> 
> BTW, I do find the general idea of '--previous' / '! --previous'
> sensible and appealing, because it wouldn't cost much to implement,
> and would give a tool to the ruleset writer to at least express
> _some_ commonality.
> 
> It's just the "upon deletion, do magic when the next rule is --previous",
> that I objected to.
> 
> best regards
>   Patrick



-- 
  lark