On 26/03/2020 10:22, Pablo Neira Ayuso wrote:
On Thu, Mar 26, 2020 at 07:17:12AM +0000, ѽ҉ᶬḳ℠ wrote:
On 22/03/2020 14:18, ѽ҉ᶬḳ℠ wrote:
How it is possible to check whether flowtable offloading actually works?
Can the populated flowtables somehow be dumped / observed / monitored?
If not mistaken the conntrack table would exhibit the [OFFLOAD] label
but observing the conntack table it does not show such label.
Reading https://lwn.net/Articles/738214/:
Patch 5/5 Switches and NICs come with built-in flow table, I've been
observing out of tree patches in OpenWRT/LEDE to integrate this into
Netfilter for a little while. This patch adds the ndo hooks to
populate hardware flow table.
This node running OpenWrt with Marvell Armada 385 88F6820 (that
supposedly features Accelerated Data Path) with integrated NIC plus an
onboard Marvell 88E6176 switch, latter driven by DSA, I am wondering
whether flowtables offloading is even expected to work in such setup?
There is no way to see/check whether flowtable offloading actually
works, or how to debug it?
As of Linux kernel 5.5, there are two ways:
* Check if [OFFLOAD] flag is shown, e.g.
# conntrack -L
tcp 6 src=192.168.10.2 dst=10.0.1.2 sport=47046 dport=5201 src=10.0.1.2 dst=10.0.1.1 sport=5201 dport=47046 [OFFLOAD] mark=0 secctx=null use=2
tcp 6 src=192.168.10.2 dst=10.0.1.2 sport=47044 dport=5201 src=10.0.1.2 dst=10.0.1.1 sport=5201 dport=47044 [OFFLOAD] mark=0 secctx=null use=2
conntrack v1.4.5 (conntrack-tools): 2 flow entries have been shown.
(you need current conntrack-tools git snapshot, this will be available
starting conntrack-tools >= 1.4.6).
* You can add a
table ip filter {
flowtable f {
hook ingress priority filter
devices = { eth0, eth1 }
}
chain forward {
type filter hook forward priority filter; policy accept;
ip protocol tcp flow add @f counter log prefix "offload: " accept
counter
}
}
You can either turn on logging after the 'flow add @f' statement for
matching packets that correspond to flows that are being offloaded.
If the flow is offloaded, the counter catch-all rule at the end of
forward should not be updated, as the packets will not follow the
classic forwarding path [1].
I'm also preparing a patchset to allow to turn on counters optionally,
so users observe that flows that have the [OFFLOAD] tag get their
counters updated.
[1] https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt
Thank you for the feedback/input.
The problem is that features, depended on certain kernel versions, are
not necessarily being backported to other LTS kernel branches and thus
not making way to downstream distros (unless maintainers make the effort
to cherry-pick and uplift commits from upstream), in this case OpenWrt.
Latter is currently deploying kernel 4.14 in the most recent stable
branch, 4.19 in the Master (development) branch and slowly transitioning
there to 5.4. Thus it will be ages (months to years) until certain
features (e.g. from 5.5) make it there.
Self cross compiling kernel / userland for SoC devices (e.g. CPE / SOHO
routers) is not easy (involving u-boot, device tree and stuff) and not
common/suitable for (most) every user.
