From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Frank Wunderlich <linux@fw-web.de>, Felix Fietkau <nbd@nbd.name>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Daniel Golle <daniel@makrotopia.org>
Cc: John Crispin <john@phrozen.org>,
Sean Wang <sean.wang@mediatek.com>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Frank Wunderlich <frank-w@public-files.de>
Subject: Re: [RFC/RFT v1] net: ethernet: mtk_eth_soc: drop generic vlan rx offload, only use DSA untagging
Date: Tue, 18 Apr 2023 12:27:59 +0300 [thread overview]
Message-ID: <e8accb50-6e46-4309-adf3-62f7445e18f2@arinc9.com> (raw)
In-Reply-To: <20230416091038.54479-1-linux@fw-web.de>
On 16.04.2023 12:10, Frank Wunderlich wrote:
> From: Felix Fietkau <nbd@nbd.name>
>
> Through testing I found out that hardware vlan rx offload support seems to
> have some hardware issues. At least when using multiple MACs and when receiving
> tagged packets on the secondary MAC, the hardware can sometimes start to emit
> wrong tags on the first MAC as well.
>
> In order to avoid such issues, drop the feature configuration and use the
> offload feature only for DSA hardware untagging on MT7621/MT7622 devices which
> only use one MAC.
I would change this part to:
In order to avoid such issues, drop the feature configuration and use
the offload feature only for DSA hardware untagging on MT7621/MT7622
devices where this feature works properly.
I tried this on linux-next with my defconfig and devicetree [0], on a
MikroTik RouterBOARD 760iGS. I tried both VLAN configurations possible,
VLAN subinterface of the eth1 interface, and bridge VLAN filtering on a
bridge with eth1 joined. In both cases, both sides receive VLAN tagged
frames whether this patch is applied or not.
My computer is plugged to the RJ45 SFP module which is connected to the
Qualcomm Atheros AR8031/AR8033 PHY which is connected to MT7621's gmac1.
My computer:
sudo ip l add link enp9s0 name enp9s0.10 type vlan id 10
sudo ip a add 192.168.3.2/24 dev enp9s0.10
sudo ip l set up enp9s0
MT7621 VLAN subinterface test:
ip l add l eth1 name eth1.10 type vlan id 10
ip a add 192.168.3.1/24 dev eth1.10
ip l set up eth1
ip l set up eth1.10
ping 192.168.3.2
MT7621 bridge VLAN filtering test:
ip l del eth1.10
ip l add br0 type bridge vlan_filtering 1
ip l set eth1 master br0
bridge v add vid 10 dev eth1
bridge v add vid 10 dev br0 self
ip l add l br0 name br0.10 type vlan id 10
ip a add 192.168.3.1/24 dev br0.10
ip l set up br0
ip l set up br0.10
ping 192.168.3.2
In conclusion, it's not that VLAN RX offloading is being kept enabled
for MT7621 because it uses only one MAC. It's because it just works. I
am assuming this is the same case for MT7622.
With that:
Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
[0] https://github.com/arinc9/linux/commits/test-on-linuxnext
Arınç
prev parent reply other threads:[~2023-04-18 9:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-16 9:10 Frank Wunderlich
2023-04-16 9:52 ` Arınç ÜNAL
2023-04-16 10:15 ` Frank Wunderlich
2023-04-16 10:55 ` Arınç ÜNAL
2023-04-16 11:09 ` Aw: " Frank Wunderlich
2023-04-18 9:27 ` Arınç ÜNAL [this message]
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=e8accb50-6e46-4309-adf3-62f7445e18f2@arinc9.com \
--to=arinc.unal@arinc9.com \
--cc=Mark-MC.Lee@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=frank-w@public-files.de \
--cc=john@phrozen.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=linux@armlinux.org.uk \
--cc=linux@fw-web.de \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sean.wang@mediatek.com \
--cc=vladimir.oltean@nxp.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
all inboxes | Powered by JetHome®