From: jamal <hadi@cyberus.ca>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Robert Iakobashvili <coroberti@gmail.com>, netdev@vger.kernel.org
Subject: Re: Network card IRQ balancing with Intel 5000 series chipsets
Date: Tue, 26 Dec 2006 17:46:39 -0500 [thread overview]
Message-ID: <1167173199.3746.45.camel@localhost> (raw)
In-Reply-To: <1167170793.3281.3209.camel@laptopd505.fenrus.org>
On Tue, 2006-26-12 at 23:06 +0100, Arjan van de Ven wrote:
> it is; that's why irqbalance tries really hard (with a few very rare
> exceptions) to keep networking irqs to the same cpu all the time...
>
The problem with irqbalance when i last used it is it doesnt take into
consideration CPU utilization.
With NAPI, if i have a few interupts it likely implies i have a huge
network load (and therefore CPU use) and would be much more happier if
you didnt start moving more interupt load to that already loaded CPU....
So if you start considering CPU load sampled over a period of time, you
could make some progress.
> but if your use case is kernel level packet processing of < MTU packets
> then I can see why you would at some point would run out of cpu
> power ...
Of course, otherwise there would be not much value in "balancing" ..
Note < MTU sized packets is not unusual for firewall/router middle boxen
and theres plenty of those out there. But these days for VOIP endpoints
(RTP and SIP) which may process such packets in user space (and handle
thousands of such flows).
Additional note: the average packet size on the internet today (and for
many years) is way below your standard ethernet MTU of 1500 bytes.
> esp on multicore where you share the cache between cores you
> probably can do a little better for that very specific use case.
Indeed - thats why i proposed to tie the IRQs statically. Modern
machines have much larger caches, so static config is less of a
nuisance.
cheers,
jamal
next prev parent reply other threads:[~2006-12-26 22:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-24 9:34 Network card IRQ balancing with Intel 5000 series chipsets Robert Iakobashvili
2006-12-25 9:35 ` Arjan van de Ven
2006-12-25 11:26 ` Robert Iakobashvili
2006-12-25 11:34 ` Arjan van de Ven
2006-12-25 12:54 ` Robert Iakobashvili
2006-12-26 18:44 ` jamal
2006-12-26 19:51 ` Robert Iakobashvili
2006-12-26 22:11 ` jamal
2007-01-02 17:56 ` Rick Jones
2006-12-26 22:06 ` Arjan van de Ven
2006-12-26 22:46 ` jamal [this message]
2006-12-27 0:28 ` Arjan van de Ven
2006-12-27 3:47 ` jamal
2006-12-27 7:09 ` Robert Iakobashvili
2006-12-27 14:31 ` jamal
2006-12-29 2:04 ` Krzysztof Oledzki
2006-12-29 17:36 ` Robert Iakobashvili
2006-12-27 13:08 ` Arjan van de Ven
2006-12-27 14:44 ` jamal
2006-12-27 15:06 ` Arjan van de Ven
2007-01-02 17:57 ` Rick Jones
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=1167173199.3746.45.camel@localhost \
--to=hadi@cyberus.ca \
--cc=arjan@infradead.org \
--cc=coroberti@gmail.com \
--cc=netdev@vger.kernel.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).