From: Risto Pajula <or.pajula@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
Heiner Kallweit <hkallweit1@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Realtek linux nic maintainers <nic_swsd@realtek.com>,
netdev@vger.kernel.org
Subject: Re: IP (rtl8169) forwarding bug (performance)
Date: Fri, 14 Dec 2018 00:10:29 +0200 [thread overview]
Message-ID: <df70a38d-19dd-7d6c-bda8-63f08e64a9b6@gmail.com> (raw)
In-Reply-To: <20181212205238.25b30922@xeon-e3>
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
next prev parent reply other threads:[~2018-12-13 22:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-02 12:01 IP fragmentation performance and don't fragment bug when forwarding Risto Pajula
2018-12-02 21:32 ` Risto Pajula
2018-12-07 14:46 ` Risto Pajula
2018-12-09 23:28 ` IP (rtl8169) forwarding bug (performance) Risto Pajula
2018-12-10 21:26 ` Heiner Kallweit
2018-12-10 22:20 ` Risto Pajula
2018-12-11 17:01 ` Risto Pajula
2018-12-11 19:51 ` Heiner Kallweit
2018-12-12 1:28 ` Risto Pajula
2018-12-12 6:23 ` Heiner Kallweit
2018-12-12 23:20 ` Risto Pajula
2018-12-13 4:52 ` Stephen Hemminger
2018-12-13 22:10 ` Risto Pajula [this message]
2018-12-13 22:30 ` Heiner Kallweit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=df70a38d-19dd-7d6c-bda8-63f08e64a9b6@gmail.com \
--to=or.pajula@gmail.com \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).