Subject: Re: [PATCH 6/6] net: move qdisc ingress filtering on top of netfilter ingress hooks

From: Daniel Borkmann <[email-masked]>
Date: Thu, 30 Apr 2015 18:09:25 +0200

On 04/30/2015 05:33 PM, Pablo Neira Ayuso wrote:
...
> On Thu, Apr 30, 2015 at 07:55:22AM -0400, Jamal Hadi Salim wrote:
> [...]
>> Start with a zero rules. Add them logarithmically (with and without
>> traffic running). i.e in order of {0, 1, 10, 100, 1000, ...}
>> With a single rule you dont notice much difference. Start adding rules
>> and it becomes very obvious.
>
> I think the days of linear ruleset performance competitions are over,

Totally agree with you. You want to have a single classification pass
that parses the packet once and comes to a verdict immediately.

> we have better data structures to allow users to arrange the ruleset
> through the multidimensional dictionaries and the arbitrary state
> flows that minimize the number of inspections, which is what it harms
> performance when it comes to packet classification.

I think both have different use cases, though, but on cls_bpf side you
have maps infrastructure that is evolving as well. Not really speaking
about the other remaining classifiers, however. I also don't want to go
any further into this vim vs emacs debate. ;) And, personally, I also
don't have any issue offering alternatives to users.

However, I still disagree with moving ingress behind this artificial
barrier if it's just not necessary. I believe, in your RFC v1 patch,
you had a second ingress hook as a static key for nft, I tend to like
that much better consensus-wise. Both subsystems should not put
unnecessary barriers into their way, really.

Best,
Daniel