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

From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Patrick McHardy <kaber@trash.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netfilter-devel@vger.kernel.org, davem@davemloft.net,
	netdev@vger.kernel.org
Subject: Re: [PATCH 6/6] net: move qdisc ingress filtering on top of netfilter ingress hooks
Date: Thu, 30 Apr 2015 17:33:17 +0200	[thread overview]
Message-ID: <20150430153317.GA3230@salvia> (raw)
In-Reply-To: <5542182A.800@mojatatu.com>

Hi jamal,

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,
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.

> ... but now your answer is essentially to subsume tc into netfilter
> ;-> Great.

We're not subsuming anything under netfilter, that hook infrastructure
is generic, and qdisc ingress will not depend on layer 3 hooks. It's
just a bit more code to allow more than one single chain from ingress
and potentially support more features from that entry point in an
optional fashion.

> ... IOW, the logic of "there are bugs
> in there, lets burn down the house" is not how we operate.

We're not burning down any house, after this patchset Qdisc ingress
will still be there. Qdisc ingress can keep going with it, fix the
bugs, improve its performance, there is way a lot room for it from its
own nice, through the flexibility that the generic hook infrastructure
provides.

> Netfilter is a lot more usable - no doubt about it. It has always
> been very good. But there are caveats.
> At one point i think we were thankful all the crackheads were using
> netfilter instead of tc because tc was harder to understand ;->.
> In retrospect i think that was wrong;->
> 
> So let me see if i can summarize your arguement:
> Hardware is faster than 1975 therefore lets just use netfilter
> for usability reasons. [...]

You keep saying that qdisc ingress outperforms, that's only right for
just a very slight difference when comparing it with no rules on
single CPU (when ported to the common playground of the generic hook
infrastructure). On SMP nftables will outperform, even more if the
ruleset is arranged in a non-linear list fashion, with all the new
tricks that we got.

Anyway, let's take this "nftables vs. qdisc ingress" discussion to an
end. I think the main point of this discussion is to provide a generic
entry point to ingress filtering (for both qdisc ingress and nftables)
that, if unused, doesn't harm performance of the critical path
netif_receive_core() path at all. Thus, users can choose what they
want, I have heard you saying several times: "To each their poison"
and I like that.

Thanks.