netdev - Aw: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <trinity-30bf2ced-ef19-4ce1-9738-07015a93dede-1679850603745@3c-app-gmx-bap64>
Date:   Sun, 26 Mar 2023 19:10:03 +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:  [PATCH net] net: ethernet: mtk_eth_soc: fix tx throughput
 regression with direct 1G links

> 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)

regards Frank