netdev - Re: r8169 tx batching(?) causing performance problems

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]

Date:   Wed, 03 Oct 2018 16:23:01 +0100
From:   David Howells <dhowells@...hat.com>
To:     Realtek linux nic maintainers <nic_swsd@...ltek.com>
Cc:     dhowells@...hat.com, netdev@...r.kernel.org, hkallweit1@...il.com
Subject: Re: r8169 tx batching(?) causing performance problems

David Howells <dhowells@...hat.com> 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 <hkallweit1@...il.com>
	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