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 <hol...@applied-asynchrony.com> Date: Fri Aug 9 00:02:40 2019 +0200 r8169: fix performance issue on RTL8168evlDisabling TSO but leaving SG active results is a significantperformance 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 <hol...@applied-asynchrony.com> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> Signed-off-by: David S. Miller <da...@davemloft.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.. -h
