Re: [nftables 0.9.2 | flow table] check whether it works?

[Pablo Neira Ayuso <pablo@netfilter.org>]

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