netdev - Re: IP (rtl8169) forwarding bug (performance)

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] [day] [month] [year] [list]

Message-ID: <a6e752cb-a7f2-c71a-c1dd-bed72b1dc6c3@gmail.com>
Date:   Thu, 13 Dec 2018 23:30:27 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Risto Pajula <or.pajula@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        netdev@...r.kernel.org
Subject: Re: IP (rtl8169) forwarding bug (performance)

On 13.12.2018 23:10, Risto Pajula wrote:
> 
> On 13.12.2018 6:52, Stephen Hemminger wrote:
>>
>> Did you disable ethernet flow control?  Ethernet flow control is
>> usually a bad idea, it can cause head of line blocking. Unfortunately,
>> most devices default to on.
> 
> Disable ethernet flow control from where? The rtl8169 driver does not support changing the ethernet flow control settings. My switches are also unmanaged.
> 
> ethtool -a eth0
> Pause parameters for eth0:
> Cannot get device pause settings: Operation not supported
> 
> According to the rtl8169 datasheet (rev 1.21 - from 2002):
> 
> "The RTL8169 enters backoff state for the specified period of time when it receives a valid PAUSE packet (with pause_time=n) in full duplex mode. If the PAUSE packet is received while the RTL8169 is transmitting, the RTL8169 starts to backoff after the current transmission is completed. The RTL8169 is free to transmit packets when it receives a valid PAUSE packet (with pause_time=0000h) or the backoff timer(=n*512 bit time) elapses."
> 
> So the transmit FIFO stalling should not be caused by this... It should automatically resume...
> 
> Also I have not seen any PAUSE frames in my traffic captures.
> 
> 
> One suspicious thing is in the datasheet:
> 
> Interrupt Status Register Bit3: "Transmit (Tx) Error: This bit set to 1 indicates that a packet transmission was aborted, due to excessive collisions, according to the TXRR's setting in the TCR register."
> 
> However in the TCR register definition there is nothing about "TXRR".
> 
A later version doesn't include the comment about TXRR.

> I could not find more recent datasheet... Could anyone provide me with one or where it could be obtained?
> 
There are no public datasheets, just one or two leaked ones. You could also check against the
r8168 vendor driver whether it handles certain things differently.
But still it's strange that it's only you who seems to have this problem. Recently I fixed one
or two issues which occurred under heavy load only. And most likely the affected users would
have recognized if the issue described by you would have occurred.

> BR.
> Risto
> 
>