From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A030C3A59E for ; Fri, 16 Aug 2019 13:59:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D4E52206C1 for ; Fri, 16 Aug 2019 13:59:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727351AbfHPN7Y (ORCPT ); Fri, 16 Aug 2019 09:59:24 -0400 Received: from mail02.iobjects.de ([188.40.134.68]:45574 "EHLO mail02.iobjects.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727296AbfHPN7X (ORCPT ); Fri, 16 Aug 2019 09:59:23 -0400 Received: from tux.wizards.de (p5DE2B998.dip0.t-ipconnect.de [93.226.185.152]) by mail02.iobjects.de (Postfix) with ESMTPSA id 3C6C24160F17; Fri, 16 Aug 2019 15:59:22 +0200 (CEST) Received: from [192.168.100.223] (ragnarok.applied-asynchrony.com [192.168.100.223]) by tux.wizards.de (Postfix) with ESMTP id 7A259F015E2; Fri, 16 Aug 2019 15:59:21 +0200 (CEST) Subject: Re: r8169: Performance regression and latency instability To: Eric Dumazet , Juliana Rodrigueiro , netdev@vger.kernel.org Cc: hkallweit1@gmail.com References: <72898d5b-9424-0bcd-3d8a-fc2e2dd0dbf1@intra2net.com> <217e3fa9-7782-08c7-1f2b-8dabacaa83f9@gmail.com> From: =?UTF-8?Q?Holger_Hoffst=c3=a4tte?= Organization: Applied Asynchrony, Inc. Message-ID: <792d3a56-32aa-afee-f2b4-1f867b9cf75f@applied-asynchrony.com> Date: Fri, 16 Aug 2019 15:59:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <217e3fa9-7782-08c7-1f2b-8dabacaa83f9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 > 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 > Signed-off-by: Heiner Kallweit > Signed-off-by: David S. Miller 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