diff mbox series

[RFC/RFT,v1] net: ethernet: mtk_eth_soc: drop generic vlan rx offload, only use DSA untagging

Message ID 20230416091038.54479-1-linux@fw-web.de (mailing list archive)
State New, archived
Headers show
Series [RFC/RFT,v1] net: ethernet: mtk_eth_soc: drop generic vlan rx offload, only use DSA untagging | expand

Commit Message

Frank Wunderlich April 16, 2023, 9:10 a.m. UTC 
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.

Tested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
and the original bug is not handled again.

it reverts changes from vladimirs patch

1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0

tested this on bananapi-r3 on non-dsa gmac1 and dsa aware eth0 (wan).
on both vlan is working, but maybe it breaks HW-vlan-untagging
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 105 ++++++++------------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |   1 -
 2 files changed, 39 insertions(+), 67 deletions(-)

Comments

Arınç ÜNAL April 16, 2023, 9:52 a.m. UTC | #1 
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.

MT7621 devices most certainly use both MACs.

> 
> Tested-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
> and the original bug is not handled again.
> 
> it reverts changes from vladimirs patch
> 
> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0

Do I understand correctly that this is considered being reverted because 
the feature it fixes is being removed?

Arınç
Frank Wunderlich April 16, 2023, 10:15 a.m. UTC | #2 
Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>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.
>
>MT7621 devices most certainly use both MACs.
>
>> 
>> Tested-by: Frank Wunderlich <frank-w@public-files.de>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
>> ---
>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
>> and the original bug is not handled again.
>> 
>> it reverts changes from vladimirs patch
>> 
>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
>
>Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?

As far as i understood, vladimirs patch fixes one
cornercase of hw rx offload where felix original
patch was fixing more..sent it as rft to you to test
if your bug (which vladimir fixed) is not coming in
again. If it does we can try to merge both
attempts. But current state has broken vlan on
bpi-r3 non-dsa gmac1 (sfp-wan).

>Arınç


regards Frank
Arınç ÜNAL April 16, 2023, 10:55 a.m. UTC | #3 
On 16.04.2023 13:15, Frank Wunderlich wrote:
> Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>> 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.
>>
>> MT7621 devices most certainly use both MACs.
>>
>>>
>>> Tested-by: Frank Wunderlich <frank-w@public-files.de>
>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
>>> ---
>>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
>>> and the original bug is not handled again.
>>>
>>> it reverts changes from vladimirs patch
>>>
>>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
>>
>> Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?
> 
> As far as i understood, vladimirs patch fixes one
> cornercase of hw rx offload where felix original
> patch was fixing more..sent it as rft to you to test
> if your bug (which vladimir fixed) is not coming in
> again. If it does we can try to merge both
> attempts. But current state has broken vlan on
> bpi-r3 non-dsa gmac1 (sfp-wan).

I tested this patch on MT7621AT and MT7623NI SoCs on the current 
linux-next. Port 0 keeps working fine.

So when you use VLANs on non-DSA gmac1, network connectivity is broken?

I've got an MT7621AT device which gmac1 is connected to an external phy 
(sfp-wan, the same case as yours). I'll test VLANs there. See if MT7621 
is affected by this as well since the patch log here states this feature 
is kept enabled for MT7621 because only gmac0 is used which is false.

Arınç
Frank Wunderlich April 16, 2023, 11:09 a.m. UTC | #4 
> Gesendet: Sonntag, 16. April 2023 um 12:55 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> On 16.04.2023 13:15, Frank Wunderlich wrote:
> > Am 16. April 2023 11:52:31 MESZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
> >> 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.
> >>
> >> MT7621 devices most certainly use both MACs.
> >>
> >>>
> >>> Tested-by: Frank Wunderlich <frank-w@public-files.de>
> >>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >>> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> >>> ---
> >>> used felix Patch as base and ported up to 6.3-rc6 which seems to get lost
> >>> and the original bug is not handled again.
> >>>
> >>> it reverts changes from vladimirs patch
> >>>
> >>> 1a3245fe0cf8 net: ethernet: mtk_eth_soc: fix DSA TX tag hwaccel for switch port 0
> >>
> >> Do I understand correctly that this is considered being reverted because the feature it fixes is being removed?
> > 
> > As far as i understood, vladimirs patch fixes one
> > cornercase of hw rx offload where felix original
> > patch was fixing more..sent it as rft to you to test
> > if your bug (which vladimir fixed) is not coming in
> > again. If it does we can try to merge both
> > attempts. But current state has broken vlan on
> > bpi-r3 non-dsa gmac1 (sfp-wan).
> 
> I tested this patch on MT7621AT and MT7623NI SoCs on the current 
> linux-next. Port 0 keeps working fine.

looks good so far ;)

> So when you use VLANs on non-DSA gmac1, network connectivity is broken?

the vlan does not work...it looks it is untagged on rx path. i see tagged frames on the other
end, send tagged back and these are not received tagged on the mac...this behaviour has brought
me to felix patch i had rebased here. the non-vlan traffic is not affected.

> I've got an MT7621AT device which gmac1 is connected to an external phy 
> (sfp-wan, the same case as yours). I'll test VLANs there. See if MT7621 
> is affected by this as well since the patch log here states this feature 
> is kept enabled for MT7621 because only gmac0 is used which is false.

good idea :)

> Arınç
Arınç ÜNAL April 18, 2023, 9:27 a.m. UTC | #5 
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ç
diff mbox series

Patch

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e14050e17862..20c60cee6aa7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1921,9 +1921,7 @@  static int mtk_poll_rx(struct napi_struct *napi, int budget,
 
 	while (done < budget) {
 		unsigned int pktlen, *rxdcsum;
-		bool has_hwaccel_tag = false;
 		struct net_device *netdev;
-		u16 vlan_proto, vlan_tci;
 		dma_addr_t dma_addr;
 		u32 hash, reason;
 		int mac = 0;
@@ -2058,31 +2056,16 @@  static int mtk_poll_rx(struct napi_struct *napi, int budget,
 			skb_checksum_none_assert(skb);
 		skb->protocol = eth_type_trans(skb, netdev);
 
-		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX) {
-			if (MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2)) {
-				if (trxd.rxd3 & RX_DMA_VTAG_V2) {
-					vlan_proto = RX_DMA_VPID(trxd.rxd4);
-					vlan_tci = RX_DMA_VID(trxd.rxd4);
-					has_hwaccel_tag = true;
-				}
-			} else if (trxd.rxd2 & RX_DMA_VTAG) {
-				vlan_proto = RX_DMA_VPID(trxd.rxd3);
-				vlan_tci = RX_DMA_VID(trxd.rxd3);
-				has_hwaccel_tag = true;
-			}
-		}
-
 		/* When using VLAN untagging in combination with DSA, the
 		 * hardware treats the MTK special tag as a VLAN and untags it.
 		 */
-		if (has_hwaccel_tag && netdev_uses_dsa(netdev)) {
-			unsigned int port = vlan_proto & GENMASK(2, 0);
+		if (!MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2) &&
+		    (trxd.rxd2 & RX_DMA_VTAG) && netdev_uses_dsa(netdev)) {
+			unsigned int port = RX_DMA_VPID(trxd.rxd3) & GENMASK(2, 0);
 
 			if (port < ARRAY_SIZE(eth->dsa_meta) &&
 			    eth->dsa_meta[port])
 				skb_dst_set_noref(skb, &eth->dsa_meta[port]->dst);
-		} else if (has_hwaccel_tag) {
-			__vlan_hwaccel_put_tag(skb, htons(vlan_proto), vlan_tci);
 		}
 
 		if (reason == MTK_PPE_CPU_REASON_HIT_UNBIND_RATE_REACHED)
@@ -2910,29 +2893,11 @@  static netdev_features_t mtk_fix_features(struct net_device *dev,
 
 static int mtk_set_features(struct net_device *dev, netdev_features_t features)
 {
-	struct mtk_mac *mac = netdev_priv(dev);
-	struct mtk_eth *eth = mac->hw;
 	netdev_features_t diff = dev->features ^ features;
-	int i;
 
 	if ((diff & NETIF_F_LRO) && !(features & NETIF_F_LRO))
 		mtk_hwlro_netdev_disable(dev);
 
-	/* Set RX VLAN offloading */
-	if (!(diff & NETIF_F_HW_VLAN_CTAG_RX))
-		return 0;
-
-	mtk_w32(eth, !!(features & NETIF_F_HW_VLAN_CTAG_RX),
-		MTK_CDMP_EG_CTRL);
-
-	/* sync features with other MAC */
-	for (i = 0; i < MTK_MAC_COUNT; i++) {
-		if (!eth->netdev[i] || eth->netdev[i] == dev)
-			continue;
-		eth->netdev[i]->features &= ~NETIF_F_HW_VLAN_CTAG_RX;
-		eth->netdev[i]->features |= features & NETIF_F_HW_VLAN_CTAG_RX;
-	}
-
 	return 0;
 }
 
@@ -3250,30 +3215,6 @@  static int mtk_open(struct net_device *dev)
 	struct mtk_eth *eth = mac->hw;
 	int i, err;
 
-	if (mtk_uses_dsa(dev) && !eth->prog) {
-		for (i = 0; i < ARRAY_SIZE(eth->dsa_meta); i++) {
-			struct metadata_dst *md_dst = eth->dsa_meta[i];
-
-			if (md_dst)
-				continue;
-
-			md_dst = metadata_dst_alloc(0, METADATA_HW_PORT_MUX,
-						    GFP_KERNEL);
-			if (!md_dst)
-				return -ENOMEM;
-
-			md_dst->u.port_info.port_id = i;
-			eth->dsa_meta[i] = md_dst;
-		}
-	} else {
-		/* Hardware special tag parsing needs to be disabled if at least
-		 * one MAC does not use DSA.
-		 */
-		u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
-		val &= ~MTK_CDMP_STAG_EN;
-		mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
-	}
-
 	err = phylink_of_phy_connect(mac->phylink, mac->of_node, 0);
 	if (err) {
 		netdev_err(dev, "%s: could not attach PHY: %d\n", __func__,
@@ -3312,6 +3253,39 @@  static int mtk_open(struct net_device *dev)
 	phylink_start(mac->phylink);
 	netif_tx_start_all_queues(dev);
 
+	if (MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2))
+		return 0;
+
+	if (mtk_uses_dsa(dev) && !eth->prog) {
+		for (i = 0; i < ARRAY_SIZE(eth->dsa_meta); i++) {
+			struct metadata_dst *md_dst = eth->dsa_meta[i];
+
+			if (md_dst)
+				continue;
+
+			md_dst = metadata_dst_alloc(0, METADATA_HW_PORT_MUX,
+						    GFP_KERNEL);
+			if (!md_dst)
+				return -ENOMEM;
+
+			md_dst->u.port_info.port_id = i;
+			eth->dsa_meta[i] = md_dst;
+		}
+	} else {
+		/* Hardware special tag parsing needs to be disabled if at least
+		 * one MAC does not use DSA.
+		 */
+		u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
+		val &= ~MTK_CDMP_STAG_EN;
+		mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
+
+		val = mtk_r32(eth, MTK_CDMQ_IG_CTRL);
+		val &= ~MTK_CDMQ_STAG_EN;
+		mtk_w32(eth, val, MTK_CDMQ_IG_CTRL);
+
+		mtk_w32(eth, 0, MTK_CDMP_EG_CTRL);
+	}
+
 	return 0;
 }
 
@@ -3796,10 +3770,9 @@  static int mtk_hw_init(struct mtk_eth *eth, bool reset)
 	if (!MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2)) {
 		val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
 		mtk_w32(eth, val | MTK_CDMP_STAG_EN, MTK_CDMP_IG_CTRL);
-	}
 
-	/* Enable RX VLan Offloading */
-	mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
+		mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
+	}
 
 	/* set interrupt delays based on current Net DIM sample */
 	mtk_dim_rx(&eth->rx_dim.work);
@@ -4437,7 +4410,7 @@  static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 		eth->netdev[id]->hw_features |= NETIF_F_LRO;
 
 	eth->netdev[id]->vlan_features = eth->soc->hw_features &
-		~(NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX);
+		~NETIF_F_HW_VLAN_CTAG_TX;
 	eth->netdev[id]->features |= eth->soc->hw_features;
 	eth->netdev[id]->ethtool_ops = &mtk_ethtool_ops;
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 084a6badef6d..ac57dc87c59a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -48,7 +48,6 @@ 
 #define MTK_HW_FEATURES		(NETIF_F_IP_CSUM | \
 				 NETIF_F_RXCSUM | \
 				 NETIF_F_HW_VLAN_CTAG_TX | \
-				 NETIF_F_HW_VLAN_CTAG_RX | \
 				 NETIF_F_SG | NETIF_F_TSO | \
 				 NETIF_F_TSO6 | \
 				 NETIF_F_IPV6_CSUM |\