All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Ahmed Zaki <anzaki@gmail.com>
Cc: netfilter-devel@vger.kernel.org, fw@strlen.de, kuba@kernel.org,
	edumazet@google.com, davem@davemloft.net, pabeni@redhat.com,
	horms@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH nf] netfilter: flowtable: tear down HW offloaded flows on FIB route changes
Date: Thu, 9 Jul 2026 19:08:49 +0200	[thread overview]
Message-ID: <ak_VoSJ7fozDdOzM@chamomile> (raw)
In-Reply-To: <20260708205404.911832-1-anzaki@gmail.com>

On Wed, Jul 08, 2026 at 02:54:04PM -0600, Ahmed Zaki wrote:
> Hardware-offloaded flows bypass the CPU and, unlike the software
> datapath, dst_check() does not invalidate them when a route changes.
> For ephemeral flows, this is usually not a problem as the flow expire on
> its own and the driver clears the entry in the HW. However, for persistent
> flows forwarded through the device, the HW is never informed that the
> route has expired.
> 
> For tables marked with NF_FLOWTABLE_HW_OFFLOAD, listen to the per-net FIB
> notifier chain and tear down the affected flows so they are re-evaluated by
> the SW forwarding path.
> 
> A lockless list is used to reduce the work items overhead in case of a
> route change storm allowing many FIB events to be processed by one work
> item.

This walks the hashtable anyway in case of fib event, maybe simply
walk over the hashtable and call dst_check() to check if the cached
dst is still current.

> Fixes: c29f74e0df7a ("netfilter: nf_flow_table: hardware offload support")

No, this is an enhancement, not a fix. This must be targeted to nf-next.

Thanks.

  parent reply	other threads:[~2026-07-09 17:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08 20:54 [PATCH nf] netfilter: flowtable: tear down HW offloaded flows on FIB route changes Ahmed Zaki
2026-07-09  6:52 ` kernel test robot
2026-07-09 17:08 ` Pablo Neira Ayuso [this message]
2026-07-09 20:33   ` Ahmed Zaki
2026-07-10  7:46 ` [syzbot ci] " syzbot ci

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ak_VoSJ7fozDdOzM@chamomile \
    --to=pablo@netfilter.org \
    --cc=anzaki@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.