From: Ben Greear <greearb@candelatech.com>
To: Donald Becker <becker@scyld.com>
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 10:44:17 -0800 [thread overview]
Message-ID: <3DC96301.7070602@candelatech.com> (raw)
In-Reply-To: Pine.LNX.4.44.0211061319220.13934-100000@beohost.scyld.com
Donald Becker wrote:
> On Wed, 6 Nov 2002, Ben Greear wrote:
>
>
>>> I see you increased the RX-ring to 1024 pkts.
>>> Did you really see any improvement with this?
>>
>>It helped drop fewer packets when running 4 ports at 92Mbps+
>>However, the difference between that and 512 is not large.
>
>
> Using 512 Rx buffers at 100Mbps seem like a pretty silly default.
I'm open to suggestions. However, I am running 4 or 8 ports simultaneously,
on a single processor machine, so w/out large receive buffers, I drop packets
horribly. If there is some magic number you think will be better than
others, I'll be happy to try it and report results...
> The trivial case is a module option that sets a variable replacing
> RX_RING_SIZE / TX_RING_SIZE..
> The passed-in value shouldn't be used directly:
> - many drivers have upper and lower bounds
> - the size can only be changed when the rings are initialized,
> which occurs when the interface starts.
So, adjusting the ring size would require stopping and starting the
NIC? Is that a full bounce (including auto-negotiation)?
> - users thinking "if 32 is good, 32000 is better"
The sad truth is, most NICs/drivers do not perform at high
speeds w/out hacking them in various ways. Where to lay the
blame (VM, shitty hardware, etc) is debatable, but it doesn't
change the results. I do know that 1024 is better than 32 for
high speeds on muliple ports, on my NICs.
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 18:44 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 [this message]
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
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=3DC96301.7070602@candelatech.com \
--to=greearb@candelatech.com \
--cc=becker@scyld.com \
--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.