From: "David S. Miller" <davem@davemloft.net>
To: jesse.brandeburg@intel.com
Cc: john.ronciak@intel.com, hadi@cyberus.ca, shemminger@osdl.org,
mitch.a.williams@intel.com, mchan@broadcom.com,
buytenh@wantstofly.org, jdmason@us.ibm.com, netdev@oss.sgi.com,
Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com
Subject: Re: RFC: NAPI packet weighting patch
Date: Tue, 07 Jun 2005 20:43:39 -0700 (PDT) [thread overview]
Message-ID: <20050607.204339.21591152.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.62.0506071852290.31708@ladlxr>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue, 7 Jun 2005 19:20:37 -0700 (PDT)
> with the 2.6.12-rc5 kernel (the old) tso promptly shuts down after a SACK,
> and after that point the machine is CPU bound at 100%. This is the point
> that we start to drop packets at the hardware level.
You're getting packet loss on the local network where you're
running these tests? Or is it simple packet reordering?
> I tried the experiment today where I replenish buffers to hardware every
> 16 packets or so. This appears to mitigate all drops at the hardware
> level (no drops). We're still at 100% with the rc5 kernel, however.
>
> even with this replenish fix, the addition of dropping the weight to 16
> helped increase our throughput, although only about 1%.
Any minor timing difference of any kind can have up to a %3 or
%4 difference in TCP performance when the receiver is CPU
limited.
> On the other hand, taking our driver as is with no changes and running the
> supertso (not the split out version, yet) kernel, we show no dropped
> packets and 60% cpu use. This combines with a 6% increase in throughput,
> and the data pattern on the wire is much more constant (i have tcpdumps,
> do you want to see them Dave?)
Yes, indeed the tcpdumps tend to look much nicer with supertso.
The 10gbit guys see regressions though. They are helping me
test things gradually in order to track down what change causes
the problems. That's why I've started rewriting super TSO from
scratch in a series of very small patches.
I don't see how supertso can help the receiver, which is where
the RX drops should be occuring. That's a little weird.
I can't believe a 2.5 GHZ machine can't keep up with a simple 1 Gbit
TCP stream. Do you have some other computation going on in that
system? As stated yesterday my 1.5 GHZ crappy sparc64 box can receive
a 1 Gbit TCP stream with much cpu to spare, my 750 MHZ sparc64 box can
nearly do so as well.
Something is up, if a single gigabit TCP stream can fully CPU
load your machine. 10 gigabit, yeah, definitely all current
generation machines are cpu limited over that link speed, but
1 gigabit should be no problem.
next prev parent reply other threads:[~2005-06-08 3:43 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-07 16:23 RFC: NAPI packet weighting patch Ronciak, John
2005-06-07 20:21 ` David S. Miller
2005-06-08 2:20 ` Jesse Brandeburg
2005-06-08 3:31 ` David S. Miller
2005-06-08 3:43 ` David S. Miller [this message]
2005-06-08 13:36 ` jamal
2005-06-09 21:37 ` Jesse Brandeburg
2005-06-09 22:05 ` Stephen Hemminger
2005-06-09 22:12 ` Jesse Brandeburg
2005-06-09 22:21 ` David S. Miller
2005-06-09 22:21 ` jamal
2005-06-09 22:22 ` David S. Miller
2005-06-09 22:20 ` jamal
-- strict thread matches above, loose matches on Subject: below --
2005-06-06 20:29 Ronciak, John
2005-06-06 23:55 ` Mitch Williams
2005-06-07 0:08 ` Ben Greear
2005-06-08 1:50 ` Jesse Brandeburg
2005-06-07 4:53 ` Stephen Hemminger
2005-06-07 12:38 ` jamal
2005-06-07 12:06 ` Martin Josefsson
2005-06-07 13:29 ` jamal
2005-06-07 12:36 ` Martin Josefsson
2005-06-07 16:34 ` Robert Olsson
2005-06-07 23:19 ` Rick Jones
2005-06-21 20:37 ` David S. Miller
2005-06-22 7:27 ` Eric Dumazet
2005-06-22 8:42 ` P
2005-06-22 19:37 ` jamal
2005-06-23 8:56 ` P
2005-06-21 20:20 ` David S. Miller
2005-06-21 20:38 ` Rick Jones
2005-06-21 20:55 ` David S. Miller
2005-06-21 21:47 ` Andi Kleen
2005-06-21 22:22 ` Donald Becker
2005-06-21 22:34 ` Andi Kleen
2005-06-22 0:08 ` Donald Becker
2005-06-22 4:44 ` Chris Friesen
2005-06-22 11:31 ` Andi Kleen
2005-06-22 16:23 ` Leonid Grossman
2005-06-22 16:37 ` jamal
2005-06-22 18:00 ` Leonid Grossman
2005-06-22 18:06 ` Andi Kleen
2005-06-22 20:22 ` David S. Miller
2005-06-22 20:35 ` Rick Jones
2005-06-22 20:43 ` David S. Miller
2005-06-22 21:10 ` Andi Kleen
2005-06-22 21:16 ` David S. Miller
2005-06-22 21:53 ` Chris Friesen
2005-06-22 22:11 ` Andi Kleen
2005-06-22 21:38 ` Eric Dumazet
2005-06-22 22:13 ` Eric Dumazet
2005-06-22 22:30 ` David S. Miller
2005-06-22 22:23 ` David S. Miller
2005-06-23 12:14 ` jamal
2005-06-23 17:36 ` David Mosberger
2005-06-22 22:42 ` Leonid Grossman
2005-06-22 23:13 ` Andi Kleen
2005-06-22 23:19 ` David S. Miller
2005-06-22 23:23 ` Andi Kleen
2005-06-22 17:05 ` Andi Kleen
2005-06-06 15:35 Ronciak, John
2005-06-06 19:47 ` David S. Miller
2005-06-03 18:19 Ronciak, John
2005-06-03 18:33 ` Ben Greear
2005-06-03 18:49 ` David S. Miller
2005-06-03 18:59 ` Ben Greear
2005-06-03 19:02 ` David S. Miller
2005-06-03 20:17 ` Robert Olsson
2005-06-03 20:30 ` David S. Miller
2005-06-03 17:40 Ronciak, John
2005-06-03 18:08 ` Robert Olsson
2005-06-03 0:11 Ronciak, John
2005-06-03 0:18 ` David S. Miller
2005-06-03 2:32 ` jamal
2005-06-03 17:43 ` Mitch Williams
2005-06-03 18:38 ` David S. Miller
2005-06-03 18:42 ` jamal
2005-06-03 19:01 ` David S. Miller
2005-06-03 19:28 ` Mitch Williams
2005-06-03 19:59 ` jamal
2005-06-03 20:31 ` David S. Miller
2005-06-03 21:12 ` Jon Mason
2005-06-03 20:22 ` David S. Miller
2005-06-03 20:29 ` David S. Miller
2005-06-03 19:49 ` Michael Chan
2005-06-03 20:59 ` Lennert Buytenhek
2005-06-03 20:35 ` Michael Chan
2005-06-03 22:29 ` jamal
2005-06-04 0:25 ` Michael Chan
2005-06-05 21:36 ` David S. Miller
2005-06-06 6:43 ` David S. Miller
2005-06-03 23:26 ` Lennert Buytenhek
2005-06-05 20:11 ` David S. Miller
2005-06-03 21:07 ` Edgar E Iglesias
2005-06-03 23:30 ` Lennert Buytenhek
2005-06-03 20:30 ` Ben Greear
2005-06-03 19:40 ` jamal
2005-06-03 20:23 ` jamal
2005-06-03 20:28 ` Mitch Williams
2005-06-02 21:19 Ronciak, John
2005-06-02 21:31 ` Stephen Hemminger
2005-06-02 21:40 ` David S. Miller
2005-06-02 21:51 ` Jon Mason
2005-06-02 22:12 ` David S. Miller
2005-06-02 22:19 ` Jon Mason
2005-06-02 22:15 ` Robert Olsson
2005-05-26 21:36 Mitch Williams
2005-05-27 8:21 ` Robert Olsson
2005-05-27 11:18 ` jamal
2005-05-27 15:50 ` Stephen Hemminger
2005-05-27 20:27 ` Mitch Williams
2005-05-27 21:01 ` Stephen Hemminger
2005-05-28 0:56 ` jamal
2005-05-31 17:35 ` Mitch Williams
2005-05-31 17:40 ` Stephen Hemminger
2005-05-31 17:43 ` Mitch Williams
2005-05-31 22:07 ` Jon Mason
2005-05-31 22:14 ` David S. Miller
2005-05-31 23:28 ` Jon Mason
2005-06-02 12:26 ` jamal
2005-06-02 17:30 ` Stephen Hemminger
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=20050607.204339.21591152.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=Robert.Olsson@data.slu.se \
--cc=buytenh@wantstofly.org \
--cc=ganesh.venkatesan@intel.com \
--cc=hadi@cyberus.ca \
--cc=jdmason@us.ibm.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=mchan@broadcom.com \
--cc=mitch.a.williams@intel.com \
--cc=netdev@oss.sgi.com \
--cc=shemminger@osdl.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).