netdev - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4a67ee73-f4ee-2099-1b5b-8d6b74acf429@nbd.name>
Date:   Sun, 26 Mar 2023 19:27:32 +0200
From:   Felix Fietkau <nbd@....name>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     netdev@...r.kernel.org, Daniel Golle <daniel@...rotopia.org>
Subject: 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.

- Felix