From: Matthew Hagan <mnhagan88@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>, netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v2] net: dsa: b53: Do not force CPU to be always tagged
Date: Wed, 9 Jun 2021 12:21:19 +0100 [thread overview]
Message-ID: <1f3e9e5f-ff5c-2fa2-7a6a-2608189a57d6@gmail.com> (raw)
In-Reply-To: <ddffc050-776f-9972-b729-a837a2a51b79@gmail.com>
Hi Florian,
On 08/06/2021 22:26, Florian Fainelli wrote:
>
> On 6/8/2021 2:22 PM, Florian Fainelli wrote:
>> Commit ca8931948344 ("net: dsa: b53: Keep CPU port as tagged in all
>> VLANs") forced the CPU port to be always tagged in any VLAN membership.
>> This was necessary back then because we did not support Broadcom tags
>> for all configurations so the only way to differentiate tagged and
>> untagged traffic while DSA_TAG_PROTO_NONE was used was to force the CPU
>> port into being always tagged.
>>
>> With most configurations enabling Broadcom tags, especially after
>> 8fab459e69ab ("net: dsa: b53: Enable Broadcom tags for 531x5/539x
>> families") we do not need to apply this unconditional force tagging of
>> the CPU port in all VLANs.
>>
>> A helper function is introduced to faciliate the encapsulation of the
>> specific condition requiring the CPU port to be tagged in all VLANs and
>> the dsa_switch_ops::untag_bridge_pvid boolean is moved to when
>> dsa_switch_ops::setup is called when we have already determined the
>> tagging protocol we will be using.
>>
>> Reported-by: Matthew Hagan <mnhagan88@gmail.com>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
> Matthew, here is a tcpdump capture showing that there is no VLAN 0 tag
> being added, unlike before:
>
> 00:00:42.191113 b8:ac:6f:80:af:7e (oui Unknown) > 00:10:18:cd:c9:c2 (oui
> Unknown), BRCM tag OP: EG, CID: 0, RC: exception, TC: 0, port: 0,
> ethertype IPv4 (0x0800), length 102: (tos 0x0, ttl 64, id 25041, offset
> 0, flags [none], proto ICMP (1), length 84)
> 192.168.1.254 > 192.168.1.10: ICMP echo reply, id 1543, seq 12,
> length 64
> 0x0000: 0010 18cd c9c2 b8ac 6f80 af7e 0000 2000 ........o..~....
> 0x0010: 0800 4500 0054 61d1 0000 4001 947f c0a8 ..E..Ta...@.....
> 0x0020: 01fe c0a8 010a 0000 4522 0607 000c 31c8 ........E"....1.
> 0x0030: 8302 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0060: 0000 0000 0000
>
> Let me know how this patch goes.
tcpdump capture on eth0 of inbound DHCP requests on port 4 of QCA switch sw1
which is attached to BCM switch port 5. Packet is VLAN tagged, VID 10.
Without patch (and without tag_qca hack):
0000 00 00 20 05 ff ff ff ff ff ff e0 cb bc 88 c9 a5 .. .............
0010 81 00 00 00 be 4c 81 00 00 0a 08 00 45 00 01 48 .....L......E..H
0020 00 00 00 00 40 11 79 a6 00 00 00 00 ff ff ff ff ....@.y.........
With patch applied:
0000 00 00 20 05 ff ff ff ff ff ff e0 cb bc 88 c9 a5 .. .............
0010 be 4c 81 00 00 0a 08 00 45 00 01 48 00 00 00 00 .L......E..H....
0020 40 11 79 a6 00 00 00 00 ff ff ff ff 00 44 00 43 @.y..........D.C
Everything seems fine. Looks good!
Matthew
next prev parent reply other threads:[~2021-06-09 11:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 21:22 [PATCH net-next v2] net: dsa: b53: Do not force CPU to be always tagged Florian Fainelli
2021-06-08 21:26 ` Florian Fainelli
2021-06-09 11:21 ` Matthew Hagan [this message]
2021-06-08 21:57 ` Vladimir Oltean
2021-06-09 11:23 ` Matthew Hagan
2021-06-09 21:00 ` patchwork-bot+netdevbpf
2021-06-09 22:30 ` Vladimir Oltean
2021-06-10 1:05 ` Florian Fainelli
-- strict thread matches above, loose matches on Subject: below --
2021-06-08 21:19 Florian Fainelli
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=1f3e9e5f-ff5c-2fa2-7a6a-2608189a57d6@gmail.com \
--to=mnhagan88@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.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).