netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@nbd.name>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Eric Woudstra <ericwouds@gmail.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jozsef Kadlecsik <kadlec@netfilter.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Frank Wunderlich <frank-w@public-files.de>,
	Daniel Golle <daniel@makrotopia.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	bridge@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements
Date: Thu, 17 Oct 2024 19:06:51 +0200	[thread overview]
Message-ID: <eb9006ae-4ded-4249-ad0e-cf5b3d97a4cb@nbd.name> (raw)
In-Reply-To: <ZxEFdX1uoBYSFhBF@calendula>

On 17.10.24 14:39, Pablo Neira Ayuso wrote:
> On Thu, Oct 17, 2024 at 11:17:09AM +0200, Felix Fietkau wrote:
> [...]
>> By the way, based on some reports that I received, I do believe that the
>> existing forwarding fastpath also doesn't handle roaming properly.
>> I just didn't have the time to properly look into that yet.
> 
> I think it should work for the existing forwarding fastpath.
> 
> - If computer roams from different port, packets follow classic path,
>    then new flow entry is created. The flow old entry expires after 30
>    seconds.
> - If route is stale, flow entry is also removed.
> 
> Maybe I am missing another possible scenario?

I'm mainly talking about the scenario where a computer moves to a 
different switch port on L2 only, so all routes remain the same.

I haven't fully analyzed the issue, but I did find a few potential 
issues with what you're describing.

1. Since one direction remains the same when a computer roams, a new 
flow entry would probably fail to be added because of an existing entry 
in the flow hash table.

2. Even with that out of the way, the MTK hardware offload currently 
does not support matching the incoming switch/ethernet port.
So even if we manage to add an updated entry, the old entry could still 
be kept alive by the hardware.

The issues I found probably wouldn't cause connection hangs in pure L3 
software flow offload, since it will use the bridge device for xmit 
instead of its members. But since hardware offload needs to redirect 
traffic to individual bridge ports, it could cause connection hangs with 
stale flow entries.

There might be other issues as well, but this is what I could come up 
with on short notice. I think in order to properly address this, we 
should probably monitor for FDB / neigh entry changes somehow and clear 
affected flows.
Routes do not become stale in my scenario, so something else is needed 
to trigger flow entry removal.

- Felix

  reply	other threads:[~2024-10-17 17:07 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-13 18:54 [PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements Eric Woudstra
2024-10-13 18:54 ` [PATCH RFC v1 net-next 01/12] netfilter: nf_flow_table_offload: Add nf_flow_encap_push() for xmit direct Eric Woudstra
2024-10-13 18:54 ` [PATCH RFC v1 net-next 02/12] netfilter: bridge: Add conntrack double vlan and pppoe Eric Woudstra
2024-10-18 13:17   ` Vladimir Oltean
2024-10-18 18:53     ` Eric Woudstra
2024-10-13 18:54 ` [PATCH RFC v1 net-next 03/12] netfilter: nft_chain_filter: Add bridge " Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 04/12] bridge: br_vlan_fill_forward_path_pvid: Add port to port Eric Woudstra
2024-10-14  6:36   ` Nikolay Aleksandrov
2024-10-13 18:55 ` [PATCH RFC v1 net-next 05/12] bridge: br_fill_forward_path add " Eric Woudstra
2024-10-14  6:30   ` Nikolay Aleksandrov
2024-10-13 18:55 ` [PATCH RFC v1 net-next 06/12] net: core: dev: Add dev_fill_bridge_path() Eric Woudstra
2024-10-14  6:59   ` Nikolay Aleksandrov
2024-10-14 18:34     ` Eric Woudstra
2024-10-16  7:43       ` Nikolay Aleksandrov
2024-10-16 15:57         ` Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 07/12] netfilter :nf_flow_table_offload: Add nf_flow_rule_bridge() Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 08/12] netfilter: nf_flow_table_inet: Add nf_flowtable_type flowtable_bridge Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 09/12] netfilter: nft_flow_offload: Add NFPROTO_BRIDGE to validate Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 10/12] netfilter: nft_flow_offload: Add DEV_PATH_MTK_WDMA to nft_dev_path_info() Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 11/12] bridge: br_vlan_fill_forward_path_mode no _UNTAG_HW for dsa Eric Woudstra
2024-10-14  6:18   ` Nikolay Aleksandrov
2024-10-14  6:22     ` Nikolay Aleksandrov
2024-10-14 14:46       ` Vladimir Oltean
2024-10-15 10:26         ` Eric Woudstra
2024-10-20  9:23           ` Eric Woudstra
2024-10-21 13:47             ` Vladimir Oltean
2024-10-22  7:25               ` Eric Woudstra
2024-10-13 18:55 ` [PATCH RFC v1 net-next 12/12] netfilter: nft_flow_offload: Add bridgeflow to nft_flow_offload_eval() Eric Woudstra
2024-10-14  6:35 ` [PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements Nikolay Aleksandrov
2024-10-14 18:29   ` Eric Woudstra
2024-10-15 12:16     ` Felix Fietkau
2024-10-15 13:32       ` Eric Woudstra
2024-10-15 19:44         ` Felix Fietkau
2024-10-16 15:59           ` Eric Woudstra
2024-10-17  9:17             ` Felix Fietkau
2024-10-17 12:39               ` Pablo Neira Ayuso
2024-10-17 17:06                 ` Felix Fietkau [this message]
2024-10-17 18:09                   ` Pablo Neira Ayuso
2024-10-17 18:39                     ` Felix Fietkau

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=eb9006ae-4ded-4249-ad0e-cf5b3d97a4cb@nbd.name \
    --to=nbd@nbd.name \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bigeasy@linutronix.de \
    --cc=bridge@lists.linux.dev \
    --cc=coreteam@netfilter.org \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ericwouds@gmail.com \
    --cc=frank-w@public-files.de \
    --cc=jiri@resnulli.us \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.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 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).