From: Florian Westphal <fw@strlen.de>
To: Eric Woudstra <ericwouds@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v4 nf-next 0/2] flow offload teardown when layer 2 roaming
Date: Thu, 2 Oct 2025 09:47:54 +0200 [thread overview]
Message-ID: <aN4uKod5GFKry2yL@strlen.de> (raw)
In-Reply-To: <20250925182623.114045-1-ericwouds@gmail.com>
Eric Woudstra <ericwouds@gmail.com> wrote:
> This patch-set can be reviewed separately from my submissions concerning
> the bridge-fastpath.
>
> In case of a bridge in the forward-fastpath or bridge-fastpath the fdb is
> used to create the tuple. In case of roaming at layer 2 level, for example
> 802.11r, the destination device is changed in the fdb.
~~~~~~~~~~~~~~~~~~
destination device == output port to use for xmit?
> The destination
> device of a direct transmitting tuple is no longer valid and traffic is
> send to the wrong destination. Also the hardware offloaded fastpath is not
> valid anymore.
Can you outline/summarize the existing behaviour for sw bridge, without
flowtable offload being in the mix here?
What is the existing behaviour without flowtable but bridge hw offload in place?
What mechanism corrects the output port in these cases?
> This flowentry needs to be torn down asap.
> Changes in v4:
> - Removed patch "don't follow fastpath when marked teardown".
> - Use a work queue to process the event.
Full walk of flowtable is expensive, how many events
are expected to be generated?
Having a few thousands of fdb updates trigger one flowtable
walk each seems like a non-starter?
next prev parent reply other threads:[~2025-10-02 7:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 18:26 [PATCH v4 nf-next 0/2] flow offload teardown when layer 2 roaming Eric Woudstra
2025-09-25 18:26 ` [PATCH v4 nf-next 1/2] netfilter: flow: Add bridge_vid member Eric Woudstra
2025-09-25 18:26 ` [PATCH v4 nf-next 2/2] netfilter: nf_flow_table_core: teardown direct xmit when destination changed Eric Woudstra
2025-10-02 7:55 ` Florian Westphal
2025-10-07 9:49 ` Eric Woudstra
2025-10-02 7:47 ` Florian Westphal [this message]
2025-10-07 8:47 ` [PATCH v4 nf-next 0/2] flow offload teardown when layer 2 roaming Eric Woudstra
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=aN4uKod5GFKry2yL@strlen.de \
--to=fw@strlen.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ericwouds@gmail.com \
--cc=horms@kernel.org \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=razor@blackwall.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).