linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nivedita Singhvi <niv@us.ibm.com>
To: Herman Dierks <hdierks@us.ibm.com>
Cc: "David S. Miller" <davem@redhat.com>,
	ltd@cisco.com, anton@samba.org, haveblue@us.ibm.com,
	scott.feldman@intel.com, dwg@au1.ibm.com,
	linux-kernel@vger.kernel.org,
	Nancy J Milliner <milliner@us.ibm.com>,
	Ricardo C Gonzalez <ricardoz@us.ibm.com>,
	Brian Twichell <twichell@us.ibm.com>,
	netdev@oss.sgi.com
Subject: Re: e1000 performance hack for ppc64 (Power4)
Date: Mon, 16 Jun 2003 09:17:37 -0700	[thread overview]
Message-ID: <3EEDEDA1.7010401@us.ibm.com> (raw)
In-Reply-To: <OF7D02DC37.06BCABE8-ON85256D46.004E9127@pok.ibm.com>

Herman Dierks wrote:
> Look folks,   we run 40 to 48  GigE adapters in a p690 32 way on AIX and
> they basically all run at full speed  so let me se you try that on most of
> these other boxes you are talking about.     Same adapter, same hardware
> logic.

FWIW, I think that's pretty cool. Not easy to do. :)

> For larger packets, like jumbo frames or large send (TSO), the few added
> DMA's is not an issue as the packets are so large the DMA soon get aligned
> and are not an issue.   With TSO being the default,   the small packet case
> becomes less important anyway.   Its more an issue on 2.4 where TSO is not
> provided.  We also want this to run well if someone does not want to use
> TSO.

Slightly off-topic, but TSO being enabled and TSO being used are
two different things, right? Ditto jumbo frames..How often is this
the actual env in real world situations? I'm concerned that this
is more typical of development testing/performance testing
environments.

> Its only the MTU 1500 case with non-TSO that we are discussing here so

Which still is the pretty important case, I think..

> copying a few bytes is really not a big deal as the data is already in
> cache from copying into kernel.  If it lets the adapter run at speed, thats
> what customers want and what we need.

Yep.

> Granted, if the HW could deal with this we would not have to, but thats not
> the case today so I want to spend a few CPU cycles to get best performance.
> Again, if this is not done on other platforms, I don't understand why you
> care.

Still would be nice to put in the best solution possible, i.e.
address it for the broadest set of affected pieces and minimizing
the impact..

> If we have to do this for PPC port, fine.   I have not seen any of you

Hope it doesn't have to come to that..It would be nice to
see it in the mainline kernel. Regardless of platform, distro, etc..
these users are still people who are taking the time, the effort to
adopt Linux and sometimes in environments and situations that are
pretty critical. Change and innovation are difficult activities
to engage in some places, and anything we can do to make this
a no-brainer solution for them, and their decisions shine, thats
gotta be worth something to go the extra mile for :)

thanks,
Nivedita



  parent reply	other threads:[~2003-06-16 16:05 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
2003-06-16 16:17 ` Nivedita Singhvi [this message]
  -- 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=3EEDEDA1.7010401@us.ibm.com \
    --to=niv@us.ibm.com \
    --cc=anton@samba.org \
    --cc=davem@redhat.com \
    --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).