Hi David,
Just for the record, this is a summary of what we have discussed so
far:
1) The existing flowtable infrastructure provides a software fast path
that is being useful for a valid number of usecases, in particular,
OpenWRT/LEDE developers/users are very enthusiastic about this.
Reason for this is that they have had no other choice rather than
loading out of tree kernel modules to enable fast forwarding paths
before this infrastructure has been mainlined. Fortunately, now
they have an upstream alternative that can help them get rid of those
modules. This fast path can be enabled very easily, actually one
single rule to select what flows follow the alternative path is
sufficient.
2) The software flowtable implementation is not affected by the
problems that flow/routing cache used to have. An attacker that
cycles through all key values by sending forged packets to fill up
the hashtable will get no entries. Ruleset policy specifies when
to offload entries into the flowtable, users can arbitrarily
decide when to push the flow into the flowtable, eg.
add rule filter forward ct status assured flow offload @x
Worst case scenario is that users need to see two packets, one on
each direction, to be able to place a flow in the flowtable.
3) There is no hardware offload integration yet. There's a public
patch - waiting to have a driver - that proposes ndo hooks, this
patch is not merged upstream. The flowtable design and the hardware
offload patch has been the result of conversations with many vendors
that represent a wide range of networking device classes, so it is
an individual effort by looking at one single device. Stateful
flowtable offload has been another main topic, pipeline is going
to stall a bit if we cannot make incremental progress towards that
direction.
Note that this batch was coming with a patch to reduce cache footprint
of the flowtable entries, so there is already working-in-progress
targeted at improving performance of this new software fast path.
Also, preparation works to introduce iptables support has been in the
radar while working on this.
We understand, we may have have spent more time in explaining all this
in the mailing list, we are trying to amend this now. Therefore, we
can probably convince someone here to write design documentation to be
placed on the Documentation/flowtable/ directory in the next pull
request if that makes it easier for the broader audience to understand
our effort and rise concerns, if any.
Thanks.
--
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
