netdev - Re: [PATCH net-next] r8169: make use of xmit

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: <CANn89iKjPz5-EypQ9cb3LRsLJBy1Hr0vLoW6Sjd_Df082H1Yzw@mail.gmail.com>
Date:   Fri, 9 Aug 2019 10:25:25 +0200
From:   Eric Dumazet <edumazet@...gle.com>
To:     Holger Hoffstätte <holger@...lied-asynchrony.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Sander Eikelenboom <linux@...elenboom.it>
Subject: Re: [PATCH net-next] r8169: make use of xmit_more

On Fri, Aug 9, 2019 at 10:04 AM Holger Hoffstätte
<holger@...lied-asynchrony.com> wrote:
>
> On 8/8/19 10:08 PM, Heiner Kallweit wrote:
> (..snip..)
> >>>
> >>> I was about to ask exactly that, whether you have TSO enabled. I don't know what
> >>> can trigger the HW issue, it was just confirmed by Realtek that this chip version
> >>> has a problem with TSO. So the logical conclusion is: test w/o TSO, ideally the
> >>> linux-next version.
> >>
> >> So disabling TSO alone didn't work - it leads to reduced throughout (~70 MB/s in iperf).
> >> Instead I decided to backport 93681cd7d94f ("r8169: enable HW csum and TSO"), which
> >> wasn't easy due to cleanups/renamings of dependencies, but I managed to backport
> >> it and .. got the same problem of reduced throughout. wat?!
> >>
> >> After lots of trial & error I started disabling all offloads and finally found
> >> that sg (Scatter-Gather) enabled alone - without TSO - will lead to the throughput
> >> drop. So the culprit seems 93681cd7d94f, which disabled TSO on my NIC, but left
> >> sg on by default. This weas repeatable - switch on sg, throughput drop; turn it
> >> off - smooth sailing, now with reduced buffers.
> >>
> >> I modified the relevant bits to disable tso & sg like this:
> >>
> >>      /* RTL8168e-vl has a HW issue with TSO */
> >>      if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
> >> +        dev->vlan_features &= ~(NETIF_F_ALL_TSO|NETIF_F_SG);
> >> +        dev->hw_features &= ~(NETIF_F_ALL_TSO|NETIF_F_SG);
> >> +        dev->features &= ~(NETIF_F_ALL_TSO|NETIF_F_SG);
> >>      }
> >>
> >> This seems to work since it restores performance without sg/tso by default
> >> and without any additional offloads, yet with xmit_more in the mix.
> >> We'll see whether that is stable over the next few days, but I strongly
> >> suspect it will be good and that the hiccups were due to xmit_more/TSO
> >> interaction.
>
> So that didn't take long - got another timeout this morning during some
> random light usage, despite sg/tso being disabled this time.
> Again the only common element is the xmit_more patch. :(
> Not sure whether you want to revert this right away or wait for 5.4-rc1
> feedback. Maybe this too is chipset-specific?
>
> > Thanks a lot for the analysis and testing. Then I'll submit the disabling
> > of SG on RTL8168evl (on your behalf), independent of whether it fixes
> > the timeout issue.
>
> Got it, thanks!
>
> Holger

I would try this fix maybe ?

diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index b2a275d8504cf099cff738f2f7554efa9658fe32..e77628813daba493ad50dab9ac1e3703e38b560c
100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5691,6 +5691,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
                 */
                smp_wmb();
                netif_stop_queue(dev);
+               door_bell = true;
        }

        if (door_bell)