[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter-devel
Subject:    Re: About matching
From:       Wang Jian <lark () linux ! net ! cn>
Date:       2005-04-07 6:13:06
Message-ID: 20050407135853.02BA.LARK () linux ! net ! cn
[Download RAW message or body]

Hi Patrick Schaaf,


On Thu, 7 Apr 2005 07:43:02 +0200, Patrick Schaaf <bof@bof.de> wrote:

> Hello Wang Jian,
> 
> > I have an idea before, that looks like the following
> > 
> > 1. A match is marked as dup when insert into chain if it has the same
> > match rule with previous;
> > 2. When a match gets deleted followed by match marked as dup , do
> > housekeeping to make sure the dup relation is correct;
> > 3. When a match is hit, if non-return, the following match marked as dup
> > is evaluated immediately as hit.
> > 
> > This can be achieved with a little code. But the problem here is when
> > used in mangle table, the target action may make the matching rule false.
> 
> The other problem is that there are several kinds of matches that
> have direct or indirect side effects when run. Consider -m limit:
> if you have two lines directly following each other, both using
> only '-m limit --limit 1/s', your dup solution would decide the
> limit only once, where the current solution presents two independant
> limits of 1/s each. There are several more matches that are like that.
> 
> These cases MUST be handled, i.e. dup logic deactivated, because it is
> not acceptable to change semantics of established rulesets just for the
> sake of efficiency (just my strong opinion).
> 

Yes. So I think --previous is a strong indication that
you-know-what-you-are-doing. With this option, kernel is instructed that
this optimization is needed, and is ok even if there are conflicts.

Because this is will not lead to crashes, I think let the user space (I
mean, users) do the work is best, actually, the user who use the rule
knows the best here.

-- 
  lark


[prev in list] [next in list] [prev in thread] [next in thread]