Hi again,

On 15/01/2026 22:04, Maxime Chevallier wrote:

Hi,

quoted

I've just run iperf3 in both directions with the kernel I had on the
board (based on 6.18.0-rc7-net-next+), and stmmac really isn't looking
particularly great - by that I mean, iperf3 *failed* spectacularly.

First, running in normal mode (stmmac transmitting, x86 receiving)
it's only capable of 210Mbps, which is nowhere near line rate.

However, when running iperf3 in reverse mode, it filled the stmmac's
receive queue, which then started spewing PAUSE frames at a rate of
knots, flooding the network, and causing the entire network to stop.
It never recovered without rebooting.

 [...]

Heh, I was able to reproduce something similar on imx8mp, that has an
imx-dwmac (dwmac 4/5 according to dmesg) :

DUT to x86

Connecting to host 192.168.2.1, port 5201
[  5] local 192.168.2.13 port 54744 connected to 192.168.2.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec    2   1.41 KBytes
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes

x86 to DUT :

Reverse mode, remote host 192.168.2.1 is sending
[  5] local 192.168.2.13 port 47050 connected to 192.168.2.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   112 MBytes   935 Mbits/sec
[  5]   1.00-2.00   sec   112 MBytes   936 Mbits/sec
[  5]   2.00-3.00   sec   112 MBytes   936 Mbits/sec

Nothing as bas as what you face, but there's defintely something going
on there. "good" news is that it worked in v6.19-rc1, I have a bisect
ongoing.

I'll update once I have homed-in on something.

Maxime

So the bisect results are in, at least for the problem I noticed. It's
not certain yet this is the same problem as Russell, and maybe not the
same as Tao Wang as well...

The culprit commit is :

commit 8409495bf6c907a5bc9632464dbdd8fb619f9ceb (HEAD)
Author: Russell King (Oracle) [off-list ref]
Date:   Thu Jan 8 17:36:40 2026 +0000

    net: stmmac: cores: remove many xxx_SHIFT definitions
    
    We have many xxx_SHIFT definitions along side their corresponding
    xxx_MASK definitions for the various cores. Manually using the
    shift and mask can be error prone, as shown with the dwmac4 RXFSTS
    fix patch.
    
    Convert sites that use xxx_SHIFT and xxx_MASK directly to use
    FIELD_GET(), FIELD_PREP(), and u32_replace_bits() as appropriate.
    
    Signed-off-by: Russell King (Oracle) [off-list ref]
    Link: https://patch.msgid.link/E1vdtw8-00000002Gtu-0Hyu@rmk-PC.armlinux.org.uk
    Signed-off-by: Jakub Kicinski [off-list ref]

Lore link :

https://lore.kernel.org/netdev/E1vdtw8-00000002Gtu-0Hyu@rmk-PC.armlinux.org.uk/ (local)

I confirm that iperf3 works perfectly in both directions before this commit,
and I get 0 bits/s when running "iperf3 -c my_host" on the DUT that has stmmac.

Looks like something happened while cleaning-up the macros for the various
definitions.

Unfortunately it's getting late here, I'm not going to dig any further
tonight :(

Thanks,

Maxime