From: Jens Axboe <jens.axboe@oracle.com>
To: Jesper Dangaard Brouer <hawk@diku.dk>
Cc: David Miller <davem@davemloft.net>,
therbert@google.com, shemminger@vyatta.com,
Eric Dumazet <dada1@cosmosbay.com>,
andi@firstfloor.org, netdev <netdev@vger.kernel.org>,
Robert Olsson <Robert.Olsson@data.slu.se>,
Jens Laas <jens.laas@ITS.UU.SE>,
hawk@comx.dk
Subject: Re: [PATCH] Software receive packet steering
Date: Thu, 23 Apr 2009 08:58:30 +0200 [thread overview]
Message-ID: <20090423065830.GN4593@kernel.dk> (raw)
In-Reply-To: <Pine.LNX.4.64.0904222156300.21763@ask.diku.dk>
On Wed, Apr 22 2009, Jesper Dangaard Brouer wrote:
> On Wed, 22 Apr 2009, David Miller wrote:
>
>> One thought I keep coming back to is the hack the block layer
>> is using right now. It remembers which CPU a block I/O request
>> comes in on, and it makes sure the completion runs on that
>> cpu too.
Hack?! :-)
It's actually nicely integrated to our existing IO completion path,
where we raise a softirq to complete the IO out of path. The only
difference now being that if you enable rq_affinity, it'll raise the
softirq potentially on a remote CPU except of always using the local
one.
> This is also very important for routing performance.
>
> Experiences from practical 10GbE routing tests (done by Roberts team and
> my self), reveals that we can only achieve (close to) 10Gbit/s routing
> performance when carefully making sure that the rx-queue and tx-queue runs
> on the same CPU. (Not doing so really kills performance).
>
> Currently I'm using some patches by Jens Låås, that allows userspace to
> setup the rx-queue to tx-queues mapping, plus manual smp_affinity tuning.
> The problem with this approach is that it requires way too much manual
> tuning from userspace to achieve good performance.
>
> I would like to see an approach with less manual tuning, as we basically
> "just" need to make sure that TX completion is done on the same CPU as RX.
> I would like to see some effort in this area and is willing to partisipate
> actively.
I saw very nice benefits on the IO side as well!
--
Jens Axboe
next prev parent reply other threads:[~2009-04-23 6:58 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
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 [this message]
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=20090423065830.GN4593@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=Robert.Olsson@data.slu.se \
--cc=andi@firstfloor.org \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=hawk@comx.dk \
--cc=hawk@diku.dk \
--cc=jens.laas@ITS.UU.SE \
--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).