On 26.03.23 19:49, Frank Wunderlich wrote:

quoted

Gesendet: Sonntag, 26. März 2023 um 19:27 Uhr
Von: "Felix Fietkau" [off-list ref]
An: "Frank Wunderlich" [off-list ref]
Cc: netdev@vger.kernel.org, "Daniel Golle" <daniel@makrotopia.org>
Betreff: Re: Aw: Re: [PATCH net] net: ethernet: mtk_eth_soc: fix tx throughput regression with direct 1G links

On 26.03.23 19:10, Frank Wunderlich wrote:

quoted

quoted

Gesendet: Sonntag, 26. März 2023 um 17:56 Uhr
Von: "Felix Fietkau" [off-list ref]
An: "Frank Wunderlich" [off-list ref]
Cc: netdev@vger.kernel.org, "Daniel Golle" <daniel@makrotopia.org>
Betreff: Re: Aw: [PATCH net] net: ethernet: mtk_eth_soc: fix tx throughput regression with direct 1G links

On 25.03.23 10:28, Frank Wunderlich wrote:

quoted

quoted

Gesendet: Freitag, 24. März 2023 um 15:04 Uhr
Von: "Felix Fietkau" [off-list ref]
An: netdev@vger.kernel.org
Cc: "Frank Wunderlich" <redacted>, "Daniel Golle" <daniel@makrotopia.org>
Betreff: [PATCH net] net: ethernet: mtk_eth_soc: fix tx throughput regression with direct 1G links

Using the QDMA tx scheduler to throttle tx to line speed works fine for
switch ports, but apparently caused a regression on non-switch ports.

Based on a number of tests, it seems that this throttling can be safely
dropped without re-introducing the issues on switch ports that the
tx scheduling changes resolved.

Link: https://lore.kernel.org/netdev/trinity-92c3826f-c2c8-40af-8339-bc6d0d3ffea4-1678213958520@3c-app-gmx-bs16/ (local)
Fixes: f63959c7eec3 ("net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues")
Reported-by: Frank Wunderlich <redacted>
Reported-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a94aa08515af..282f9435d5ff 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c

@@ -763,8 +763,6 @@ static void mtk_mac_link_up(struct phylink_config *config,
 		break;
 	}
 
-	mtk_set_queue_speed(mac->hw, mac->id, speed);
-
 	/* Configure duplex */
 	if (duplex == DUPLEX_FULL)
 		mcr |= MAC_MCR_FORCE_DPX;

thx for the fix, as daniel already checked it on mt7986/bpi-r3 i tested bpi-r2/mt7623

but unfortunately it does not fix issue on bpi-r2 where the gmac0/mt7530 part is affected.

maybe it needs a special handling like you do for mt7621? maybe it is because the trgmii mode used on this path?

Could you please test if making it use the MT7621 codepath brings back 
performance? I don't have any MT7623 hardware for testing right now.

Hi,

this seems to make the CPU stall (after kernel is loaded completely when userspace begins to start):

-       if (IS_ENABLED(CONFIG_SOC_MT7621)) {
+       if (IS_ENABLED(CONFIG_SOC_MT7621) || IS_ENABLED(CONFIG_SOC_MT7623)) {

[   27.252672] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[   27.258618] rcu:     2-...0: (0 ticks this GP) idle=54c4/1/0x40000000 softir8
[   27.266973] rcu:     (detected by 1, t=2102 jiffies, g=-891, q=7 ncpus=4)
[   27.273499] Sending NMI from CPU 1 to CPUs 2:
                                                                                 
[USBD] USB PRB0 LineState: 0

wonder why this happens...i expected some kind of tranmit queue erros with trace...

full log here
https://pastebin.com/de4dZDt4

but i've found no error there (sorry for cutting on the right side...my terminal window was to small)

The change you made has no effect, because CONFIG_SOC_MT7623 does not 
exist, so there must be something else that broke your system.
Try CONFIG_MACH_MT7623 instead, once you've resolved the system hang.

it was exactly this change above...dropping it fixed it

do not know why i did no compile-error, looked into implementation of IS_ENABLED which is passed through different defines till

include/linux/kconfig.h:42:#define ___is_defined(val)		____is_defined(__ARG_PLACEHOLDER_##val)
include/linux/kconfig.h:43:#define ____is_defined(arg1_or_junk)	__take_second_arg(arg1_or_junk 1, 0)
include/linux/kconfig.h:14:#define __take_second_arg(__ignored, val, ...) val

i do not expect that there is anything wrong, just wonder why this stalls...

used the CONFIG_MACH_MT7623 (which is set in my config) boots up fine, but did not fix the 622Mbit-tx-issue

and i'm not sure i have tested it before...all ports of mt7531 are affected, not only wan (i remembered you asked for this)

Does the MAC that's connected to the switch use flow control? Can you 
test if changing that makes a difference?

- Felix