From: Ben Greear <greearb@candelatech.com>
To: Robert Olsson <Robert.Olsson@data.slu.se>
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1
Date: Wed, 06 Nov 2002 13:30:56 -0800 [thread overview]
Message-ID: <3DC98A10.5030407@candelatech.com> (raw)
In-Reply-To: 15817.29109.859144.565330@robur.slu.se
Robert Olsson wrote:
> Ben Greear writes:
> I still doubt ;-)
>
> With e1000 I played with various settings for RX-buffers rather recently
> when the 82544 increased the number of available buffers from 256 to 4096.
>
> And I guess my test looks a bit like yours... Injecting an "overload" of
> packets. I found was 256 buffers was the optimum. Approximative of course.
It's possible that it is a particular issue with my NICs (Old Phobos 4-port).
Phobos folks said the bridge chipset has errata that make it un-suitable for
high speeds. And something about a memory divide-by-four error. It may be
that the extra buffers help hide the hardware defects in some manner.
I was, for instance, seeing cases where packets just dissappeared...and no
error counters were being bumped.
With the latest kernel drivers, the 570tx NIC seems to have
trouble autonegotiating full-duplex again, so I have not been testing
with it lately (I think it uses the same bridge chipset anyway.)
I will try changing around those numbers again now that I have a baseline
to work from.
> And as you saw for SMP with recycle it is easy to feed the recycled skb
> back to CPU were it was created/processed.
Yes, I can see how that would be useful on SMP, so there may be less gain
for single-proc systems. I actually am pretty fuzzy on cache-line optimizations
and the like...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
next prev parent reply other threads:[~2002-11-06 21:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-06 6:36 NAPI-ized tulip patch against 2.4.20-rc1 Ben Greear
2002-11-06 6:42 ` Ben Greear
2002-11-06 17:34 ` Robert Olsson
2002-11-06 17:49 ` Ben Greear
2002-11-06 18:31 ` Donald Becker
2002-11-06 18:44 ` Ben Greear
2002-11-06 20:47 ` Donald Becker
2002-11-07 7:08 ` Ben Greear
2002-11-07 13:24 ` jamal
2002-11-07 18:16 ` greear
2002-11-07 21:26 ` Robert Olsson
2002-11-07 21:25 ` Ben Greear
2002-11-07 23:29 ` Ben Greear
2002-11-08 11:30 ` jamal
2002-11-08 17:40 ` Ben Greear
2002-11-07 12:57 ` jamal
2002-11-06 19:47 ` Robert Olsson
2002-11-06 21:30 ` Ben Greear [this message]
2002-11-07 12:48 ` jamal
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=3DC98A10.5030407@candelatech.com \
--to=greearb@candelatech.com \
--cc=Robert.Olsson@data.slu.se \
--cc=netdev@oss.sgi.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 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.