[<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