From: Andre Tomt <andre@tomt.net>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Frank Reppin <frank@undermydesk.org>,
netdev@vger.kernel.org,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
e1000-devel@lists.sourceforge.net
Subject: Re: [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
Date: Wed, 10 Oct 2012 00:48:42 +0200 [thread overview]
Message-ID: <5074A9CA.50308@tomt.net> (raw)
In-Reply-To: <20121009103629.0000569a@unknown>
On 09. okt. 2012 19:36, Jesse Brandeburg wrote:
> I'm not sure what went wrong internally here that this hasn't been
> fixed, and I'm personally embarrassed. I am working on it until I have
> a patch/solution.
>
> currently am trying to reproduce the issue, am in some weird how to
> use BQL limbo, the lack of documentation on user usage of BQL is slowing
> me down.
>
> Hints or clues (I'm trying to follow the repro steps mentioned in
> some related threads) are appreciated.
I found it simplest to reproduce when doing forwarding, and *not*
saturating the interface doing the TX. 100Mbps forwarding on gigabit
link triggered it in seconds. Doing gigabit forwarding speeds (~980Mbps)
did not trigger anything.
Setup looked somewhat like this, GE beeing gigabit link, FE 100Mbps;
reciever PC (iperf -s)
|
GE
|
eth0 <- TX lockups
router with 2*e1000e
eth1
|
GE
|
switch
|
FE
|
source PC (iperf -c recieverPC)
I don't recall all the details anymore, but I'm fairly certain I didnt
use any non-default qdiscs to reproduce - eg just pfifo_fast (usually
doing fq_codel though).
For the bug to manifest itself was somewhat dependent on GRO and TSO in
kernel 3.5, but with 3.6 it didnt matter anymore (at least the rc's).
next prev parent reply other threads:[~2012-10-09 22:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-06 8:43 [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls Hiroaki SHIMODA
2012-06-06 8:46 ` Jeff Kirsher
2012-06-06 8:50 ` Eric Dumazet
2012-06-07 0:59 ` Jeff Kirsher
2012-06-07 1:34 ` David Miller
2012-06-07 4:24 ` Eric Dumazet
2012-06-07 4:52 ` Jeff Kirsher
2012-06-07 5:03 ` Eric Dumazet
2012-10-09 0:25 ` Frank Reppin
2012-10-09 6:07 ` Eric Dumazet
2012-10-09 17:36 ` Jesse Brandeburg
2012-10-09 21:02 ` Eric Dumazet
2012-10-09 22:48 ` Andre Tomt [this message]
2012-10-10 1:25 ` Frank Reppin
-- strict thread matches above, loose matches on Subject: below --
2012-10-11 1:34 [PATCH NET] " Jesse Brandeburg
2012-10-11 3:00 ` David Miller
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=5074A9CA.50308@tomt.net \
--to=andre@tomt.net \
--cc=e1000-devel@lists.sourceforge.net \
--cc=eric.dumazet@gmail.com \
--cc=frank@undermydesk.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.