netdev - Aw: Re: Re: [PATCH net] net: ethernet: mtk_eth_soc: fix tx throughput regression with direct 1G links

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <trinity-6b2ecbe5-7ad8-4740-b691-8b9868fae223-1679852966887@3c-app-gmx-bap64>
Date:   Sun, 26 Mar 2023 19:49:26 +0200
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     Felix Fietkau <nbd@....name>
Cc:     netdev@...r.kernel.org, Daniel Golle <daniel@...rotopia.org>
Subject: Aw: Re:  Re: [PATCH net] net: ethernet: mtk_eth_soc: fix tx
 throughput regression with direct 1G links

> Gesendet: Sonntag, 26. März 2023 um 19:27 Uhr
> Von: "Felix Fietkau" <nbd@....name>
> An: "Frank Wunderlich" <frank-w@...lic-files.de>
> Cc: netdev@...r.kernel.org, "Daniel Golle" <daniel@...rotopia.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:
> >> Gesendet: Sonntag, 26. März 2023 um 17:56 Uhr
> >> Von: "Felix Fietkau" <nbd@....name>
> >> An: "Frank Wunderlich" <frank-w@...lic-files.de>
> >> Cc: netdev@...r.kernel.org, "Daniel Golle" <daniel@...rotopia.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:
> >> >> Gesendet: Freitag, 24. März 2023 um 15:04 Uhr
> >> >> Von: "Felix Fietkau" <nbd@....name>
> >> >> An: netdev@...r.kernel.org
> >> >> Cc: "Frank Wunderlich" <frank-w@...lic-files.de>, "Daniel Golle" <daniel@...rotopia.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/
> >> >> Fixes: f63959c7eec3 ("net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues")
> >> >> Reported-by: Frank Wunderlich <frank-w@...lic-files.de>
> >> >> Reported-by: Daniel Golle <daniel@...rotopia.org>
> >> >> Tested-by: Daniel Golle <daniel@...rotopia.org>
> >> >> Signed-off-by: Felix Fietkau <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)

regards Frank