[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6f8e86d-62ee-4fc8-a92d-3fc6e963433c@gmail.com>
Date: Tue, 5 Nov 2024 22:28:17 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Felix Braun <f.braun@...ix.de>, nic_swsd@...ltek.com
Cc: netdev@...r.kernel.org
Subject: Re: r8169: regression in connection speed with kernels 6.2+
(interrupt coalescing)
On 05.11.2024 20:57, Felix Braun wrote:
>
> On 04.11.2024 14:57 +0100 Heiner Kallweit wrote:
>> On 04.11.2024 13:47, Felix Braun wrote:
>>> Nono, I mean 100MBytes/s ;-) My testcase is transferring a large file over
> SMB and looking at the transfer speed as reported by KDE. (I'm attaching a full
> dmsg of a boot of a 6.11.6 kernel with only irq_coalescing commented out
> otherwise as released.)
>>>
>>
>> This test case involves several layers. To rule out conflicts on higher
> levels:
>> Can you test with iperf to another machine in the same local network?
>
> Measuring the performance with iperf3 I still see a difference in throughput by
> a factor of 3:
>
> WITH napi_defer_hard_irqs=0
> ===========================
> [ 5] local 2001:a61:11c6:9501:982a:b19f:94fc:71d1 port 41716 connected to
> 2001:a61:11c6:9501:97a8:b80a:4317:435e port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 315 KBytes
> [ 5] 1.00-2.00 sec 110 MBytes 927 Mbits/sec 0 340 KBytes
> [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 0 372 KBytes
> [ 5] 3.00-4.00 sec 111 MBytes 930 Mbits/sec 0 372 KBytes
> [ 5] 4.00-5.00 sec 110 MBytes 926 Mbits/sec 0 372 KBytes
> [ 5] 5.00-6.00 sec 111 MBytes 929 Mbits/sec 0 372 KBytes
> [ 5] 6.00-7.00 sec 110 MBytes 924 Mbits/sec 0 372 KBytes
> [ 5] 7.00-8.00 sec 111 MBytes 932 Mbits/sec 0 372 KBytes
> [ 5] 8.00-9.00 sec 110 MBytes 924 Mbits/sec 0 372 KBytes
> [ 5] 9.00-10.00 sec 111 MBytes 928 Mbits/sec 0 372 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec 0 sender
> [ 5] 0.00-10.00 sec 1.08 GBytes 928 Mbits/sec receiver
>
> WITH napi_defer_hard_irqs=1
> ===========================
> Connecting to host leporello, port 5201
> [ 5] local 2001:a61:11c6:9501:982a:b19f:94fc:71d1 port 42338 connected to
> 2001:a61:11c6:9501:97a8:b80a:4317:435e port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 37.0 MBytes 310 Mbits/sec 0 806 KBytes
> [ 5] 1.00-2.00 sec 35.0 MBytes 294 Mbits/sec 0 806 KBytes
> [ 5] 2.00-3.00 sec 35.1 MBytes 294 Mbits/sec 0 806 KBytes
> [ 5] 3.00-4.00 sec 35.0 MBytes 294 Mbits/sec 0 806 KBytes
> [ 5] 4.00-5.00 sec 35.2 MBytes 296 Mbits/sec 0 806 KBytes
> [ 5] 5.00-6.00 sec 35.0 MBytes 294 Mbits/sec 0 806 KBytes
> [ 5] 6.00-7.00 sec 34.9 MBytes 293 Mbits/sec 0 806 KBytes
> [ 5] 7.00-8.00 sec 34.9 MBytes 293 Mbits/sec 0 806 KBytes
> [ 5] 8.00-9.00 sec 35.0 MBytes 294 Mbits/sec 0 806 KBytes
> [ 5] 9.00-10.00 sec 35.2 MBytes 295 Mbits/sec 0 806 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 352 MBytes 296 Mbits/sec 0 sender
> [ 5] 0.00-10.02 sec 349 MBytes 292 Mbits/sec receiver
>
Could you please test also in the other direction (with option -R)?
>
>> Would be worth a try to see how system behaves with ASPM enabled in the
> kernel.
>> Even though BIOS denies ASPM access for the kernel:
>> "can't disable ASPM; OS doesn't have ASPM control"
>
> I noticed that I disabled ASPM in the BIOS. So far I've not been able to find a
> BIOS setting that makes that warning go away.
>
> If you think, that the current settings are the best default values for most
> users, I'd defer your better knowledge of the hardware. At least I'm happy
> because I can get my performance back by disabling IRQ coalescing on a vanilla
> kernel.
>
On a small N100-based system I can't reproduce the issue with the same chip version.
Even 2.5Gbps works with full line speed on this system.
OK, your CPU is even weaker, but this still shouldn't cause such a performance drop.
More the opposite, as software interrupt coalescing reduces the CPU load.
However there's nothing special with your system, according to the dmesg log.
> Regards
> Felix
Heiner
Powered by blists - more mailing lists