netdev - Re: r8169: regression in connection speed with kernels 6.2+ (interrupt coalescing)

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: <324136cf-80f5-4d3d-8583-85b603794187@gmail.com>
Date: Mon, 4 Nov 2024 14:57:19 +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 04.11.2024 13:47, Felix Braun wrote:
> On 03.11.2024 23:21 +0100 Heiner Kallweit wrote:  
>> Thanks for the report. 6.2 has been out for quite some time, and this is  
>> the first such report. So I don't think there's a general problem.
> 
> I switched from 6.1 (stable) to 6.6 (stable) only recently and then I didn't notice the speed degradation for quite some time.
> 
>> Can you please provide a full dmesg log and elaborate on the type of traffic  
>> and how you measure the speed? BTW: With 100MB/s you refer to 100MBit/s?
> 
> 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?

SMB file transfers are a standard use case, so I would have expected at least some
complaints if performance drops to 10%. So something seems to be special with your system.

>> Also interesting would be whether there are any errors or missed packets  
>> in the ethtool -S <if> output.
> 
> No errors or misses in either patched or unpatched kernel.
> 
>> Instead of commenting out this line you can also adjust the values from userspace:  
>> /sys/class/net/<if>/gro_flush_timeout  
>> /sys/class/net/<if>/napi_defer_hard_irqs  
>> Does increasing the gro_flush_timeout value change something for you?
> 
> That's cool. I've reverted to unchanged 6.11.6 and if I set napi_defer_hard_irqs to 0 I'm back to 100 MBytes/s. Playing with gro_flush_timeout while napi_defer_hard_irqs is set to 1 does not seem to have any effect on the trasfer speed. Default value is 20000. I have tried some values between 1000 and 200000.
> 
>> Somewhat strange is that lspci shows ASPM as disabled in LnkCtl, but  
>> L1 sub-states are enabled in L1SubCtl1. Do you have any downstream kernel code  
>> changes or any specific ASPM settings?
> 
> No. Other than patching the default value for interrupt coalescing, I'm running a vanilla kernel. Maybe it is because I didn't enable ASPM in the kernel configuration?
> 
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"

> Thanks for taking this up.
> 
> Regards  
> Felix

Heiner