From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: r8169 tx batching(?) causing performance problems Date: Wed, 03 Oct 2018 16:23:01 +0100 Message-ID: <20168.1538580181@warthog.procyon.org.uk> References: <23097.1538562476@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: dhowells@redhat.com, netdev@vger.kernel.org, hkallweit1@gmail.com To: Realtek linux nic maintainers Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46900 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726748AbeJCWLy (ORCPT ); Wed, 3 Oct 2018 18:11:54 -0400 In-Reply-To: <23097.1538562476@warthog.procyon.org.uk> Content-ID: <20167.1538580181.1@warthog.procyon.org.uk> Sender: netdev-owner@vger.kernel.org List-ID: David Howells wrote: > Can someone help me figure out a performance issue that seems to be caused by > an RTL8168g/8111g NIC that seems to be batching up transmissions - or, at > least, not starting immediately that it's given something to transmit? I've been told that: commit ad5f97faff4231e72b96bd96adbe1b6e977a9b86 Author: Heiner Kallweit Date: Fri Sep 28 23:51:54 2018 +0200 r8169: fix network stalls due to missing bit TXCFG_AUTO_FIFO might fix the problem, however it doesn't seem to help entirely. Whilst it does now seem to be transmitting whilst I'm generating up the queue, it still seems that I'm able to load up the queue faster the packets are being cleared from the queue. So in the following excerpt: id-0 [001] d.h2 41.284702: net_rtl8169_interrupt: enp3s0 st=85 id-0 [001] ..s2 41.284715: net_rtl8169_poll: enp3s0 st=85 dd-3186 [003] ...3 41.284741: net_rtl8169_tx: enp3s0 p=213-216 skb=2e2b0c3e dd-3186 [003] ...3 41.284777: net_rtl8169_tx: enp3s0 p=213-217 skb=3950deca dd-3186 [003] ...3 41.284790: net_rtl8169_tx: enp3s0 p=213-218 skb=471b2bc2 dd-3186 [003] ...3 41.284826: net_rtl8169_tx: enp3s0 p=213-219 skb=7c25ae16 dd-3186 [003] ...3 41.284839: net_rtl8169_tx: enp3s0 p=213-220 skb=cfbf719f dd-3186 [003] ...3 41.284870: net_rtl8169_tx: enp3s0 p=213-221 skb=d34a1f67 dd-3186 [003] ...3 41.284883: net_rtl8169_tx: enp3s0 p=213-222 skb=466e20e8 dd-3186 [003] ...3 41.284914: net_rtl8169_tx: enp3s0 p=213-223 skb=3d36cb1c dd-3186 [003] ...3 41.284927: net_rtl8169_tx: enp3s0 p=213-224 skb=399c06ea id-0 [001] ..s2 41.284938: net_rtl8169_tx_done: enp3s0 p=213 skb=c797fea6 id-0 [001] ..s2 41.284939: net_rtl8169_tx_done: enp3s0 p=214 skb=c0e4d6f0 id-0 [001] ..s2 41.284940: net_rtl8169_tx_done: enp3s0 p=215 skb=2e2b0c3e id-0 [001] ..s2 41.284941: net_rtl8169_tx_done: enp3s0 p=216 skb=3950deca id-0 [001] ..s2 41.284941: net_rtl8169_tx_done: enp3s0 p=217 skb=471b2bc2 id-0 [001] ..s2 41.284942: net_rtl8169_tx_done: enp3s0 p=218 skb=7c25ae16 id-0 [001] ..s2 41.284943: net_rtl8169_tx_done: enp3s0 p=219 skb=cfbf719f id-0 [001] ..s2 41.284944: net_rtl8169_tx_done: enp3s0 p=220 skb=d34a1f67 id-0 [001] ..s2 41.284945: net_rtl8169_tx_done: enp3s0 p=221 skb=466e20e8 id-0 [001] ..s2 41.284946: net_rtl8169_tx_done: enp3s0 p=222 skb=3d36cb1c id-0 [001] ..s2 41.284947: net_rtl8169_tx_done: enp3s0 p=223 skb=399c06ea id-0 [001] d.h2 41.284954: net_rtl8169_interrupt: enp3s0 st=85 packets are being queued something like 11-13uS apart, but there seems like a big gap of about 200uS in the idle thread between the poll and the first tx_done that might be masking things. David