Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> Hi,
>
> This patchset provides the combo match for payload and the iifname and
> oifname meta selector. The idea is to track and coalesce expressions in
> an internal special combo expression. This batch adds support to coalesce
> the following expressions:
>
> payload + cmp
> payload + bitwise + cmp
> meta {iifname,oifname} + cmp
Interesting concept, thanks for exploring this.
> The coalesce happens when the ruleset blob is built, the expression
> tracking is done at rule level, ie. by iterating over the expressions
> that represent the rule. The expression tracking happens twice, once to
> calculate the ruleset blob (because the combo expression alters the
> expected rule data size) and then to build the ruleset blob.
This might be useful for other representation transformations, cf. the
pending 'remove register zeroing' patchset.
If that breaks 3rd party users we can now simply force the zeroing
from the internal ruleset representation.
> This batch replaces the existing approach which based on fast variants
> of the cmp and bitwise expressions, that are also removed.
I think its good to re-evaluate the eval loop from time to time
and axe whats not needed anymore.
> This approach is an alternative to the register track & reduce approach,
> which so far works at chain level. Such approach requires descending the
> tree of chains and tracking registers from base to leaf chains, this
> becomes more complicated with dynamic ruleset, but it could be useful
> for static rulesets, such approach also requires significant updates in
> userspace. Therefore, I'm inclined towards this more simple solution.
I like this approach.
> One question with this update is whether removing the fast bitwise and
> cmp variants slows down other (non-coalesced) expressions. The results
> I collected with a simple ruleset to test worst case scenario like this:
>
> -m state --state ESTABLISHED -j DROP
> ... 99 times more
> -m state --state NEW -j DROP [ <- this is the matching rule ]
Oh, I was about to ask if you're using an out-of-tree version but
then I saw you picked this to test *absence* of any cmp/bitwise.
> shows 301 Mb/s without this patchset vs 412 Mb/s with this patchset,
Did not expect such a big difference.
> that it, results are better with this patchset while the payload and
> meta expression that are coalesced show much better numbers.
>
> I'm collecting more detailed numbers, I will post them soon.
Excellent, thanks! I think this is a good appraoch, I will review
patches in more detail soon.
