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: Tue, 27 Apr 2021 12:27:58 +0300 [thread overview]
Message-ID: <20210427092758.uejhxl7ahuulf34m@skbuf> (raw)
In-Reply-To: <8735vcoztz.fsf@waldekranz.com>
On Tue, Apr 27, 2021 at 11:12:56AM +0200, Tobias Waldekranz wrote:
> On Mon, Apr 26, 2021 at 23:28, Vladimir Oltean <olteanv@gmail.com> wrote:
> > On Mon, Apr 26, 2021 at 10:05:52PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 26, 2021 at 22:40, Vladimir Oltean <olteanv@gmail.com> wrote:
> >> > 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?
> >>
> >> I am not sure I follow. The bridge would never send the packet to
> >> swp{4,5} because should_deliver() rejects them (as usual). So it could
> >> only be sent either to swp2 or swp3. In the case that swp3 is first in
> >> the bridge's port list, it would be sent untagged, but the PVID would be
> >> 100 and the flooding would thus be limited to swp{2,3}.
> >
> > Sorry, _I_ don't understand.
> >
> > When you say that the PVID is 100, whose PVID is it, exactly? Is it the
> > pvid of the source port (aka eth0 in this example)? That's not what I
> > see, I see the pvid of the egress port (the Marvell device)...
>
> I meant the PVID of swp3.
>
> In summary: This series incorrectly assumes that a port's PVID always
> corresponds to the VID that should be assigned to untagged packets on
> egress. This is wrong because PVID only specifies which VID to assign
> packets to on ingress, it says nothing about policy on egress. Multiple
> VIDs can also be configured to egress untagged on a given port. The VID
> must thus be sent along with each packet in order for the driver to be
> able to assign it to the correct VID.
>
> > So to reiterate: when you transmit a packet towards your hardware switch
> > which has br0 inside the sb_dev, how does the switch know in which VLAN
> > to forward that packet? As far as I am aware, when the bridge had
> > received the packet as untagged on eth0, it did not insert VLAN 100 into
> > the skb itself, so the bridge VLAN information is lost when delivering
> > the frame to the egress net device. Am I wrong?
>
> VID 100 is inserted into skb->vlan_tci on ingress from eth0, in
> br_vlan.c/__allowed_ingress. It is then cleared again in
> br_vlan.c/br_handle_vlan if the egress port (swp3 in our example) is set
> to egress the VID untagged.
>
> The last step only clears skb->vlan_present though, the actual VID
> information still resides in skb->vlan_tci. I tried just removing 5/9
> from this series, and then sourced the VID from skb->vlan_tci for
> untagged packets. It works like a charm! I think this is the way
> forward.
>
> The question is if we need another bit of information to signal that
> skb->vlan_tci contains valid information, but the packet should still be
> considered untagged? This could also be used on Rx to carry priority
> (PCP) information to the bridge.
My expectation is that when you do this forwarding offload thing, the
bridge passes the classified VLAN down to the port driver, encoded
inside the accel_priv alongside the sb_dev somehow.
next prev parent reply other threads:[~2021-04-27 9:28 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
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 [this message]
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=20210427092758.uejhxl7ahuulf34m@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).