From: Vladimir Oltean <olteanv@gmail.com>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
vivien.didelot@gmail.com, f.fainelli@gmail.com, roopa@nvidia.com,
nikolay@nvidia.com, jiri@resnulli.us, idosch@idosch.org,
stephen@networkplumber.org, netdev@vger.kernel.org,
bridge@lists.linux-foundation.org
Subject: Re: [RFC net-next 5/9] net: dsa: Track port PVIDs
Date: Mon, 26 Apr 2021 22:40:26 +0300 [thread overview]
Message-ID: <20210426194026.3sr22rqyf2srrwtq@skbuf> (raw)
In-Reply-To: <20210426170411.1789186-6-tobias@waldekranz.com>
Hi Tobias,
On Mon, Apr 26, 2021 at 07:04:07PM +0200, Tobias Waldekranz wrote:
> In some scenarios a tagger must know which VLAN to assign to a packet,
> even if the packet is set to egress untagged. Since the VLAN
> information in the skb will be removed by the bridge in this case,
> track each port's PVID such that the VID of an outgoing frame can
> always be determined.
>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> ---
Let me give you this real-life example:
#!/bin/bash
ip link add br0 type bridge vlan_filtering 1
for eth in eth0 eth1 swp2 swp3 swp4 swp5; do
ip link set $eth up
ip link set $eth master br0
done
ip link set br0 up
bridge vlan add dev eth0 vid 100 pvid untagged
bridge vlan del dev swp2 vid 1
bridge vlan del dev swp3 vid 1
bridge vlan add dev swp2 vid 100
bridge vlan add dev swp3 vid 100 untagged
reproducible on the NXP LS1021A-TSN board.
The bridge receives an untagged packet on eth0 and floods it.
It should reach swp2 and swp3, and be tagged on swp2, and untagged on
swp3 respectively.
With your idea of sending untagged frames towards the port's pvid,
wouldn't we be leaking this packet to VLAN 1, therefore towards ports
swp4 and swp5, and the real destination ports would not get this packet?
next prev parent reply other threads:[~2021-04-26 19:40 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 17:04 [RFC net-next 0/9] net: bridge: Forward offloading Tobias Waldekranz
2021-04-26 17:04 ` [RFC net-next 1/9] net: dfwd: Constrain existing users to macvlan subordinates Tobias Waldekranz
2021-04-26 17:04 ` [RFC net-next 2/9] net: bridge: Disambiguate offload_fwd_mark Tobias Waldekranz
2021-05-02 15:00 ` Ido Schimmel
2021-05-03 8:49 ` Tobias Waldekranz
2021-05-05 7:39 ` Ido Schimmel
2021-04-26 17:04 ` [RFC net-next 3/9] net: bridge: switchdev: Recycle unused hwdoms Tobias Waldekranz
2021-04-27 10:42 ` Nikolay Aleksandrov
2021-04-26 17:04 ` [RFC net-next 4/9] net: bridge: switchdev: Forward offloading Tobias Waldekranz
2021-04-27 10:35 ` Nikolay Aleksandrov
2021-04-28 22:47 ` Tobias Waldekranz
2021-04-29 9:16 ` Nikolay Aleksandrov
2021-04-29 14:55 ` Tobias Waldekranz
2021-05-02 15:04 ` Ido Schimmel
2021-05-03 8:53 ` Tobias Waldekranz
2021-05-06 11:01 ` Vladimir Oltean
2021-04-26 17:04 ` [RFC net-next 5/9] net: dsa: Track port PVIDs Tobias Waldekranz
2021-04-26 19:40 ` Vladimir Oltean [this message]
2021-04-26 20:05 ` Tobias Waldekranz
2021-04-26 20:28 ` Vladimir Oltean
2021-04-27 9:12 ` Tobias Waldekranz
2021-04-27 9:27 ` Vladimir Oltean
2021-04-27 10:07 ` Vladimir Oltean
2021-04-28 23:10 ` Tobias Waldekranz
2021-04-26 17:04 ` [RFC net-next 6/9] net: dsa: Forward offloading Tobias Waldekranz
2021-04-27 10:17 ` Vladimir Oltean
2021-05-04 14:44 ` Tobias Waldekranz
2021-05-04 15:21 ` Vladimir Oltean
2021-05-04 20:07 ` Tobias Waldekranz
2021-05-04 20:33 ` Andrew Lunn
2021-05-04 21:24 ` Tobias Waldekranz
2021-05-04 20:58 ` Vladimir Oltean
2021-05-04 22:12 ` Tobias Waldekranz
2021-05-04 23:04 ` Vladimir Oltean
2021-05-05 9:01 ` Tobias Waldekranz
2021-05-05 16:12 ` Vladimir Oltean
2021-04-26 17:04 ` [RFC net-next 7/9] net: dsa: mv88e6xxx: Allocate a virtual DSA port for each bridge Tobias Waldekranz
2021-04-26 17:04 ` [RFC net-next 8/9] net: dsa: mv88e6xxx: Map virtual bridge port in PVT Tobias Waldekranz
2021-04-26 17:04 ` [RFC net-next 9/9] net: dsa: mv88e6xxx: Forward offloading Tobias Waldekranz
2021-05-02 14:58 ` [RFC net-next 0/9] net: bridge: " Ido Schimmel
2021-05-03 9:44 ` Tobias Waldekranz
2021-05-06 10:59 ` Vladimir Oltean
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=20210426194026.3sr22rqyf2srrwtq@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
--cc=roopa@nvidia.com \
--cc=stephen@networkplumber.org \
--cc=tobias@waldekranz.com \
--cc=vivien.didelot@gmail.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).