From: Ben Hutchings <bhutchings@solarflare.com>
To: Tom Herbert <therbert@google.com>
Cc: David Miller <davem@davemloft.net>,
shemminger@vyatta.com, netdev@vger.kernel.org
Subject: Re: [PATCH] Software receive packet steering
Date: Thu, 09 Apr 2009 19:23:32 +0100 [thread overview]
Message-ID: <1239301412.3264.24.camel@achroite> (raw)
In-Reply-To: <65634d660904090943lf273d9cg92be105acef3e6af@mail.gmail.com>
On Thu, 2009-04-09 at 09:43 -0700, Tom Herbert wrote:
> >>> -extern int netif_receive_skb(struct sk_buff *skb);
> >>> +extern int __netif_receive_skb(struct sk_buff *skb);
> >>> +
> >>> +static inline int netif_receive_skb(struct sk_buff *skb)
> >>> +{
> >>> +#ifdef CONFIG_NET_SOFTRPS
> >>> + return netif_rx(skb);
> >>> +#else
> >>> + return __netif_receive_skb(skb);
> >>> +#endif
> >>> +}
> >>
> >> Ugh, this forces all devices receiving back into a single backlog
> >> queue.
> >
> > Yes, it basically turns off NAPI.
> >
>
> NAPI is still useful, but it does take a higher packet load before
> polling kicks in. I believe this is similarly true for HW multi
> queue, and could actually be worse depending on the number of queues
> traffic is being split across (in my bnx2x experiment 16 core AMD with
> 16 queues, I was seeing around 300K interrupts per second, no benefit
> from NAPI).
[...]
Have you tried using fewer than 16 queues? We found using every core in
a multi-core package to be a waste of cycles.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2009-04-09 18:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 22:48 [PATCH] Software receive packet steering Tom Herbert
2009-04-08 23:08 ` Stephen Hemminger
2009-04-08 23:09 ` Stephen Hemminger
2009-04-08 23:15 ` David Miller
2009-04-09 16:43 ` Tom Herbert
2009-04-09 18:23 ` Ben Hutchings [this message]
2009-04-09 21:17 ` David Miller
2009-04-09 0:36 ` David Miller
2009-04-09 4:40 ` Tom Herbert
2009-04-09 5:24 ` David Miller
2009-04-20 10:32 ` Andi Kleen
2009-04-20 10:46 ` David Miller
2009-04-21 3:26 ` Tom Herbert
2009-04-21 9:48 ` Eric Dumazet
2009-04-21 15:46 ` Stephen Hemminger
2009-04-21 18:52 ` Tom Herbert
2009-04-22 9:21 ` David Miller
2009-04-22 15:46 ` Tom Herbert
2009-04-22 18:49 ` Rick Jones
2009-04-22 20:44 ` Jesper Dangaard Brouer
2009-04-23 6:58 ` Jens Axboe
2009-04-23 7:25 ` David Miller
2009-04-23 7:29 ` Jens Axboe
2009-04-23 9:12 ` Jens Laas
2009-04-22 14:33 ` Martin Josefsson
2009-04-23 7:34 ` 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=1239301412.3264.24.camel@achroite \
--to=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=therbert@google.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).