netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Laas <jens.laas@its.uu.se>
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, jens.axboe@oracle.com
Subject: Re: [PATCH] Software receive packet steering
Date: Thu, 23 Apr 2009 11:12:49 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0904231036400.4832@jens.its.uu.se> (raw)
In-Reply-To: <Pine.LNX.4.64.0904222156300.21763@ask.diku.dk>

(09.04.22 kl.22:44) Jesper Dangaard Brouer skrev följande till David Miller:

> 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.
>
> 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.

We have a C-program for setting the affinity correctly. Note that 
"correctly" very much depends on your setup and what you want to do.
We started with a script for doing this, but its a bit easier to implement 
some heuristics in a proper program.

The patch (which implements a concept called "flowtrunks") also requires 
setup from userspace (via ethtool ioctl). We dont actually use this yet in 
production.

The natural way to go forward would be to implement in userspace a program 
that can tune smp_affinity and queue-mapping (maybe via flowtrunks) 
together. With knowledge of the setup and userpreference this should be 
doable to automatically tune your system for you.

One advantage with flowtrunks (generic queue/nic to/from flowtrunk 
mapping) would be for us to not have to patch every supported nic.
Plus we could tune the system for more than one usecase (forwarding 
between multi-queue nics).
The main object of the flowtrunk patch was to try to start a discussion 
and create something concrete to help our thinking. 
This problem-space needs to be explored.

>
> 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 dont see a problem with tuning from userspace. I think it will be hard 
for the kernel to automatically tune all types of setups for all usecases. 
Maybe Im just lacking in imagination though.

Cheers,
Jens

>
> Cheers,
>  Jesper Brouer
>
> --
> -------------------------------------------------------------------
> MSc. Master of Computer Science
> Dept. of Computer Science, University of Copenhagen
> Author of http://www.adsl-optimizer.dk
> -------------------------------------------------------------------

-----------------------------------------------------------------------
     'In theory, there is no difference between theory and practice.
      But, in practice, there is.'
-----------------------------------------------------------------------
     Jens Låås                              Email: jens.laas@its.uu.se
     ITS                                    Phone: +46 18 471 77 03
     SWEDEN
-----------------------------------------------------------------------

  parent reply	other threads:[~2009-04-23  9:16 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
2009-04-23  7:25                 ` David Miller
2009-04-23  7:29                   ` Jens Axboe
2009-04-23  9:12               ` Jens Laas [this message]
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=Pine.LNX.4.64.0904231036400.4832@jens.its.uu.se \
    --to=jens.laas@its.uu.se \
    --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.axboe@oracle.com \
    --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).