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

Message-ID: <df70a38d-19dd-7d6c-bda8-63f08e64a9b6@gmail.com>
Date:   Fri, 14 Dec 2018 00:10:29 +0200
From:   Risto Pajula <or.pajula@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        Heiner Kallweit <hkallweit1@...il.com>
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 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".

I could not find more recent datasheet... Could anyone provide me with 
one or where it could be obtained?

BR.
Risto