netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Robert Olsson <Robert.Olsson@data.slu.se>
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>,
	Jeff Garzik <jgarzik@mandrakesoft.com>
Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1
Date: Wed, 06 Nov 2002 09:49:37 -0800	[thread overview]
Message-ID: <3DC95631.6030001@candelatech.com> (raw)
In-Reply-To: 15817.21170.173913.829498@robur.slu.se

Robert Olsson wrote:
> Ben Greear writes:
>  > Here is a patch that makes Tulip support NAPI.  The vast bulk of these
>  > changes come from Robert Olsson's ftp site, I just pieced them together.
>  > 
>  > It works good on my 4-port Tulip NICs, better than the default
>  > driver at least (no, I never tried the old HW-Mitigation option).
>  > 
>  > This patch will also make use of Robert's skb-recycle patch if it's
>  > been applied, but through #ifdef magic, it should also work w/out
>  > that....
> 
>  Hello!
> 
>  Well skb recycling is "research" and should be used to challange to vm/slab
>  people to start with... And I guess you will get objections about the extra 
>  stats as well.

The stats stuff is #ifdef'd out, as is the skb-recycling stuff.

> 
>  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.
I would really like to make that size adjustable at module load
time and/or runtime, but I'm not sure how easy that would be.

Imagine being able to crank up your receive buffers when running at
very high speeds (and/or when you start dropping packets).  At lower speeds,
shrink things down and free up resources....


>  Also I would be interested if you have any numbers for recycling patch? 

I still need to do some comparisons with that being the only difference.
I do know that it does not appear to hurt anything, but it's also possible
that it doesn't really help.  Since under normal circumstances there are
enough buffers to be allocated with GFP_ATOMIC, I believe that it will take
long statistical runs to determine if this really helps.  I do like very
much the fact that it actually gives me something deterministic to tune though,
so I'll keep it for that reason if nothing else.

>  Jamal and I spent some days after OLS to test and tune but it wasn't to 
>  promising at that time but it's reworked now.

Were you testing SMP or uni-processor?  I've been doing the tulip testing
on a single processor P-IV system.

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

  reply	other threads:[~2002-11-06 17:49 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 [this message]
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
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=3DC95631.6030001@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=Robert.Olsson@data.slu.se \
    --cc=jgarzik@mandrakesoft.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 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).