Re: [PATCH nf,v2] netfilter: flowtable: tear down flow entries with stale dst from GC

On Sun, Jul 12, 2026 at 1:27 PM Pablo Neira Ayuso <[email protected]> wrote:
>
> On Sun, Jul 12, 2026 at 07:39:25AM -0600, Ahmed Zaki wrote:
> > On Sat, Jul 11, 2026 at 3:02 PM Pablo Neira Ayuso <[email protected]> wrote:
> > >
.
.
.
>
> > > fa7395c02d95 netfilter: flowtable: support IPIP tunnel with direct xmit
> > > 6c5dcab95f4c netfilter: flowtable: IPIP tunnel hardware offload is not yet support
> > > c328b90c17fc netfilter: flowtable: use dst in this direction when pushing IPIP header
> > >
> > > There is also this patch which is needed:
> > >
> > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/[email protected]/
> > >
> > > which has been included in the last PR this Friday.
> >
> > I have some limitations so I can only test with 6.6 or 6.12. I will
> > try to trim down these patches to
> > "move dst_cache out of union and use the gc to check all entries" and
> > will let you know if I see
> > any more problems.
>
> You will have to backport the move of dst_cache out of the union.
>

yes, and I tested for a couple of hours with no issues. GC was taking
care of the
expired dst_cache.

> > The one thing I believe is still missing is to remove the if condition
> > in flow_offload_fill_route()
> > when setting  "flow_tuple->dst_cache/dst_cookie":
> >
> > - if (route->tuple[!dir].in.num_tuns) {
> >
> > We now need "flow_tuple->dst_cache/dst_cookie" for all DIRECT xmit
> > even with no tunnels
>
> How so? ->dst_cache is not available when sending packets to a port
> behind a master bridge device.

Sorry I must be missing something. I do not have a bridge in my setup. I have a
Mediatek PPE that is offloading from one port to another and there are
no bridges:

# nft list ruleset
table ip fw4 {
    flowtable f1 {
        hook ingress priority filter
        devices = { eth0, eth1 }
        flags offload
    }

chain forward {
    type filter hook forward priority filter; policy accept;
    tcp dport 5201 flow add @f1
    }
}

My previous comment is that in this case, AFAIK, the "xmit_type =
DIRECT" and in order
to set dst_cache/cookie, the guard "if
(route->tuple[!dir].in.num_tuns)" needs to be
taken away (which I did in my 6.6 patch, let me know if you want me to
send this as ref).

Thank you.