From: jamal <hadi@cyberus.ca>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, shemminger@linux-foundation.org,
jgarzik@pobox.com, rusty@rustcorp.com.au
Subject: Re: [PATCH RFC]: napi_struct V4
Date: Wed, 25 Jul 2007 08:01:14 -0400 [thread overview]
Message-ID: <1185364874.26013.192.camel@localhost> (raw)
In-Reply-To: <20070725.013154.34764933.davem@davemloft.net>
On Wed, 2007-25-07 at 01:31 -0700, David Miller wrote:
> We're getting there, slowly...
>
> 1) netif_napi_init() is added, the workqueue/requeue stuff
> as discussed is not needed so you won't see that here
..
....
> Another thing that's really apparent now is all the wacky
> napi->weight values various drivers use. Just grep for
> netif_napi_init() in the patch or a patched tree to see what
> I mean. So much of it doesn't make any sense and I'm tempted
> to just remove the argument and make everyone use 32 or 64
> or something like that :-) Or, default to some value across
> the board, and let drivers override that on a case by case
> basis with a BIG FAT COMMENT above the override describing
> why the different value is being used and precisely what
> tests were performed to validate that different value.
Sounds reasonable.
32-64 for Gige seemed to work well as i recall. 10/100 was around 16.
But that shouldnt matter i think: because the poll from the core is
based on Varghese's DRR, it probably will be fine if you just gave all
the same value and the "deficit" part will kick in when needed. Some
testing maybe required but theoretically i dont see a problem.
BTW: The current kernel code has a "bug" - where if a driver
forgot to set its weight it would be indeterminate, so even for this
reason it will be a good idea to enforce a default.
Sorry, havent been following the thread - thanks for CCing me, will try
to catch up at some point.
cheers,
jamal
next prev parent reply other threads:[~2007-07-25 12:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-25 8:31 [PATCH RFC]: napi_struct V4 David Miller
2007-07-25 8:56 ` Stephen Hemminger
2007-07-26 0:37 ` David Miller
2007-07-26 1:55 ` Jeff Garzik
2007-07-26 1:56 ` David Miller
2007-07-26 2:00 ` Jeff Garzik
2007-07-26 2:02 ` David Miller
2007-07-28 18:08 ` Jeff Garzik
2007-07-29 5:33 ` David Miller
2007-07-25 12:01 ` jamal [this message]
2007-07-26 4:09 ` David Miller
2007-07-26 6:33 ` Michael Chan
2007-07-26 6:38 ` David Miller
2007-07-26 7:05 ` Michael Chan
2007-07-26 7:15 ` David Miller
2007-07-26 21:38 ` Michael Chan
2007-07-31 0:25 ` David Miller
2007-07-26 6:39 ` Michael Chan
2007-07-26 6:43 ` David Miller
2007-07-28 15:27 ` Roland Dreier
2007-07-29 5:32 ` David Miller
2007-07-30 15:04 ` Roland Dreier
2007-07-30 22:48 ` David Miller
2007-07-31 2:01 ` Roland Dreier
2007-07-31 2:03 ` David Miller
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=1185364874.26013.192.camel@localhost \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=jgarzik@pobox.com \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=shemminger@linux-foundation.org \
/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).