On 2018-03-12 19:58, David Miller wrote:

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 12 Mar 2018 18:58:50 +0100

quoted

The following patchset contains Netfilter/IPVS updates for your net-next
tree. This batch comes with more input sanitization for xtables to
address bug reports from fuzzers, preparation works to the flowtable
infrastructure and assorted updates. In no particular order, they are:

Sorry, I've seen enough.  I'm not pulling this.

What is the story with this flow table stuff?  I tried to ask you
about this before, but the response I was given was extremely vague
and did not answer my question at all.

This is a lot of code, and a lot of infrastructure, yet I see
no device using the infrastructure to offload conntack.

Nor can I see how this can possibly be even useful for such an
application.  What conntrack offload needs are things completely
outside of what the flow table stuff provides.  Mainly, they
require that the SKB is completely abstracted away from all of
the contrack code paths, and that the conntrack infrastructure
operates on an abstract packet metadata concept.

If you are targetting one specific piece of hardware with TCAMs
that you are familiar with.  I'd like you to stop right there.
Because if that is all that this infrastructure can actually
be used for, it is definitely designed wrong.

This, as has been the case in the past, is what is wrong with
netfilter approach to supporting offloading.  We see all of this
infrastructure before an actual working use case is provided for a
specific piece of hardware for a specific driver in the tree.

Nobody can evaluate whether the approach is good or not without
a clear driver change implementing support for it.

No other area of networking puts the cart before the horse like this.

I do not agree at all with the flow table infrastructure and I
therefore do not want to pull any more flow table changes into my tree
until there is an actual user of this stuff in that pull request which
actually works in a way which is useful for people.  It is completely
dead and useless code currently.

It's not dead and useless. In its current state, it has a software fast
path that significantly improves nftables routing/NAT throughput,
especially on embedded devices.
On some devices, I've seen "only" 20% throughput improvement (along with
CPU usage reduction), on others it's quite a bit lot more. This is
without any extra drivers or patches aside from what's posted.

Within OpenWrt, I'm working on a patch that makes the same available to
legacy netfilter as well. This is the reason for a lot of the core
refactoring that I did.

Hardware offload is still being worked on, not sure when we will have
the first driver ready. But as it stands now, the code is already very
useful and backported to OpenWrt for testing.

I think that in a couple of weeks this code will be ready to be enabled
by default in OpenWrt, which means that a lot of users' setups will get
a lot faster with no configuration change at all.

- Felix