From: Vladimir Oltean <olteanv@gmail.com>
To: Eric Woudstra <ericwouds@gmail.com>
Cc: 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>,
Pablo Neira Ayuso <pablo@netfilter.org>,
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, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH RFC v1 net-next 11/12] bridge: br_vlan_fill_forward_path_mode no _UNTAG_HW for dsa
Date: Mon, 21 Oct 2024 16:47:26 +0300 [thread overview]
Message-ID: <20241021134726.dzfz5uu2peyin3kk@skbuf> (raw)
In-Reply-To: <785f6b7a-1de1-46fe-aa6f-9b20feee5973@gmail.com>
On Sun, Oct 20, 2024 at 11:23:18AM +0200, Eric Woudstra wrote:
> So after doing some more reading, at creation of the code using
> BR_VLFLAG_ADDED_BY_SWITCHDEV would have been without problems.
>
> After the switchdev was altered so that objects from foreign devices can
> be added, it is problematic in br_vlan_fill_forward_path_mode(). I have
> tested and indeed any foreign device does have this problem.
>
> So we need a way to distinguish in br_vlan_fill_forward_path_mode()
> whether or not we are dealing with a (dsa) foreign device on the switchdev.
>
> I have come up with something, but this is most likely to crude to be
> accepted, but for the sake of 'rfc' discussing it may lead to a proper
> solution. So what does work is the following patch, so that
> netif_has_dsa_foreign_vlan() can be used inside
> br_vlan_fill_forward_path_mode().
>
> Any suggestions on how this could be implemented properly would be
> greatly appreciated.
I don't know nearly enough about the netfilter flowtable to even
understand exactly the problem you're describing and are trying to solve.
I've started to read up on things, but plenty of concepts are new and
I'm mixing this with plenty of other activities. If you could share some
commands to build a test setup so I could form my own independent
opinion of what is going on, it would be great as it would speed up that
process.
With respect to the patch you've posted, it doesn't look exactly great.
One would need to make a thorough analysis of the bridge's use of
BR_VLFLAG_ADDED_BY_SWITCHDEV, of whether it still makes sense in today's
world where br_switchdev_vlan_replay() is a thing (a VLAN that used to
not be "added by switchdev" can become "added by switchdev" after a
replay, but this flag will remain incorrectly unset), of whether VLANs on
foreign DSA interfaces should even have this flag set, and on whether
your flowtable forwarding path patches are conceptually using it correctly.
There's a lot to think about, and if somebody doesn't have the big picture,
I'm worried that a wrong decision will be taken.
next prev parent reply other threads:[~2024-10-21 13:47 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 [this message]
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
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=20241021134726.dzfz5uu2peyin3kk@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--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=f.fainelli@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