From: "David S. Miller" <davem@redhat.com>
To: hdierks@us.ibm.com
Cc: ltd@cisco.com, anton@samba.org, haveblue@us.ibm.com,
scott.feldman@intel.com, dwg@au1.ibm.com,
linux-kernel@vger.kernel.org, milliner@us.ibm.com,
ricardoz@us.ibm.com, twichell@us.ibm.com, netdev@oss.sgi.com
Subject: Re: e1000 performance hack for ppc64 (Power4)
Date: Sun, 15 Jun 2003 07:44:05 -0700 (PDT) [thread overview]
Message-ID: <20030615.074405.39168044.davem@redhat.com> (raw)
In-Reply-To: <OF7D02DC37.06BCABE8-ON85256D46.004E9127@pok.ibm.com>
From: "Herman Dierks" <hdierks@us.ibm.com>
Date: Sun, 15 Jun 2003 09:40:41 -0500
With TSO being the default, the small packet case
becomes less important anyway.
This is a very narrow and unrealistic view of the situation.
Every third packet your system will process for any connection will be
an ACK, a small packet. Most database and web and database
transactions happen using small packets for the transaction request.
Look, if you're gonna sit here and just rant justifying this bogus
behavior of your hardware, it is likely to go in one ear and out the
other. Nobody wants to hear excuses. :)
The fact is, this system handles sub-cacheline reads inefficiently
even if a sequences of transactions are consequetive and to the same
cache line and no coherency transactions occur to that cache line.
That is dumb, and there is no arguing around this. You would be
sensible to realize this, and accept it whilst others try to help you
find a solution for your problem.
next prev parent reply other threads:[~2003-06-15 14:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-15 14:40 e1000 performance hack for ppc64 (Power4) Herman Dierks
2003-06-15 14:44 ` David S. Miller [this message]
2003-06-16 16:17 ` Nivedita Singhvi
-- strict thread matches above, loose matches on Subject: below --
2003-06-16 18:56 Feldman, Scott
2003-06-16 18:21 Feldman, Scott
2003-06-16 18:30 ` Dave Hansen
2003-06-15 14:32 Herman Dierks
2003-06-13 23:52 Feldman, Scott
2003-06-13 23:52 ` David S. Miller
2003-06-14 0:55 ` Anton Blanchard
2003-06-14 1:34 ` David S. Miller
2003-06-14 0:03 ` Anton Blanchard
2003-06-13 22:13 Feldman, Scott
2003-06-13 17:03 Herman Dierks
2003-06-13 15:17 Herman Dierks
2003-06-13 16:21 ` Dave Hansen
2003-06-13 22:38 ` Anton Blanchard
2003-06-13 22:46 ` David S. Miller
2003-06-13 23:18 ` Anton Blanchard
2003-06-14 1:52 ` Lincoln Dale
2003-06-14 5:41 ` David S. Miller
2003-06-14 5:52 ` Lincoln Dale
2003-06-14 6:08 ` David S. Miller
2003-06-14 6:14 ` David S. Miller
2003-06-14 6:27 ` William Lee Irwin III
2003-06-14 17:08 ` Greg KH
2003-06-14 17:19 ` Greg KH
2003-06-14 17:21 ` Riley Williams
2003-06-15 3:01 ` David S. Miller
2003-06-14 5:16 ` Nivedita Singhvi
2003-06-14 5:36 ` David S. Miller
2003-06-13 1:16 Feldman, Scott
2003-06-13 23:15 ` Anton Blanchard
2003-06-12 3:32 David Gibson
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=20030615.074405.39168044.davem@redhat.com \
--to=davem@redhat.com \
--cc=anton@samba.org \
--cc=dwg@au1.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=hdierks@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ltd@cisco.com \
--cc=milliner@us.ibm.com \
--cc=netdev@oss.sgi.com \
--cc=ricardoz@us.ibm.com \
--cc=scott.feldman@intel.com \
--cc=twichell@us.ibm.com \
/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).