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: <8fa71d82-d309-df38-5924-2275db188b61@gmail.com>
Date:   Fri, 16 Aug 2019 21:12:49 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Holger Hoffstätte <holger@...lied-asynchrony.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Juliana Rodrigueiro <juliana.rodrigueiro@...ra2net.com>,
        netdev@...r.kernel.org
Subject: Re: r8169: Performance regression and latency instability

On 16.08.2019 15:59, Holger Hoffstätte wrote:
> On 8/16/19 2:35 PM, Eric Dumazet wrote:
> ..snip..
>> I also see this relevant commit : I have no idea why SG would have any relation with TSO.
>>
>> commit a7eb6a4f2560d5ae64bfac98d79d11378ca2de6c
>> Author: Holger Hoffstätte <holger@...lied-asynchrony.com>
>> Date:   Fri Aug 9 00:02:40 2019 +0200
>>
>>      r8169: fix performance issue on RTL8168evl
>>           Disabling TSO but leaving SG active results is a significant
>>      performance drop. Therefore disable also SG on RTL8168evl.
>>      This restores the original performance.
>>           Fixes: 93681cd7d94f ("r8169: enable HW csum and TSO")
>>      Signed-off-by: Holger Hoffstätte <holger@...lied-asynchrony.com>
>>      Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>>      Signed-off-by: David S. Miller <davem@...emloft.net>
> 
> It does not - and admittedly none of this makes sense, but stay with me here.
> 
> The commit 93681cd7d94f to net-next enabled rx/tx HW checksumming and TSO
> by default, but disabled TSO for one specific chip revision - the most popular
> one, of course. Enabling rx/tx checksums by default while leaving SG on turned
> out to be the performance issue (~780 MBit max) that I found & fixed in the
> quoted commit. SG *can* be enabled when rx/tx checkusmming is *dis*abled
> (I just verified again), we just had to sanitize the new default.
> 
> An alternative strategy could still be to (again?) disable everything by default
> and just let people manually enable whatever settings work for their random
> chip revision + BIOS combination. I'll let Heiner chime in here.
> 
> Basically these chips are dumpster fires and should not be used for anything
> ever, which of course means they are everywhere.
> 
> AFAICT none of this has anything to do with Juliana's problem..
> 
Indeed, here we're talking about changes in linux-next, and Juliana's issue is
with 4.19. However I'd appreciate if Juliana could test with linux-next and
different combinations of the NETIF_F_xxx features.

I have no immediate idea why the referenced GSO change affects r8169 but not
other chips / drivers.

> -h
> 
Heiner

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ