On 12/03/2018 20:58, David Miller wrote:
From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
Date: Mon, 12 Mar 2018 18:58:50 +0100
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.
Hi David,
Pablo's code is a very welcome addition to the flow tables infrastructure.
We at Mellanox already have customers asking for Offload of Connection
Tracking.
While a complete hardware implementation is yet to arrive. Pablo's
contribution is blessed.
Using this infrastructure we are capable of completely offloading
connection tracking (Without TCP window validation)
and possibly do a complete offload once hardware support for TCP window
Validation shows up.
I'm currently working closely with Pablo to create the first driver
implementation to utilize
hardware offloading. Needless to say - prior to having hardware
implementation a software infrastructure is required.
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.
Assuming that the software maintains the flow in the system,
it is reasonable to allow software do the connection establishment and
termination
and let the hardware do all the rest between (again - without TCP window
validation, unless a specialized hardware exists)
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.
I'm speaking on behalf of Mellanox.
Would one driver support as demonstration suffice?
Thanks,
Guy
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
