All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Tom Herbert <therbert@google.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH v5] rps: Receive Packet Steering
Date: Thu, 14 Jan 2010 14:56:33 -0800	[thread overview]
Message-ID: <20100114145633.4c2d4ac6@nehalam> (raw)
In-Reply-To: <alpine.DEB.1.00.1001141353140.19018@pokey.mtv.corp.google.com>

On Thu, 14 Jan 2010 13:56:23 -0800 (PST)
Tom Herbert <therbert@google.com> wrote:

> This patch implements software receive side packet steering (RPS).  RPS
> distributes the load of received packet processing across multiple CPUs.
> 
> Problem statement: Protocol processing done in the NAPI context for received
> packets is serialized per device queue and becomes a bottleneck under high
> packet load.  This substantially limits pps that can be achieved on a single
> queue NIC and provides no scaling with multiple cores.
> 
> This solution queues packets early on in the receive path on the backlog queues
> of other CPUs.   This allows protocol processing (e.g. IP and TCP) to be
> performed on packets in parallel.   For each device (or NAPI instance for
> a multi-queue device) a mask of CPUs is set to indicate the CPUs that can
> process packets for the device. A CPU is selected on a per packet basis by
> hashing contents of the packet header (the TCP or UDP 4-tuple) and using the
> result to index into the CPU mask.  The IPI mechanism is used to raise
> networking receive softirqs between CPUs.  This effectively emulates in
> software what a multi-queue NIC can provide, but is generic requiring no device
> support.
> 
> Many devices now provide a hash over the 4-tuple on a per packet basis
> (Toeplitz is popular).  This patch allow drivers to set the HW reported hash
> in an skb field, and that value in turn is used to index into the RPS maps.
> Using the HW generated hash can avoid cache misses on the packet when
> steering the packet to a remote CPU.
> 
> The CPU masks is set on a per device basis in the sysfs variable
> /sys/class/net/<device>/rps_cpus.  This is a set of canonical bit maps for
> each NAPI nstance of the device.  For example:
> 
> echo "0b 0b0 0b00 0b000" > /sys/class/net/eth0/rps_cpus

Why not make a kobject out of cpus which would add subdirectory.
This would keep interface consistent with the one value per file
semantic of sysfs.

  reply	other threads:[~2010-01-14 22:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14 21:56 [PATCH v5] rps: Receive Packet Steering Tom Herbert
2010-01-14 22:56 ` Stephen Hemminger [this message]
2010-01-14 23:31   ` Rick Jones
2010-01-16  2:11   ` Ben Hutchings
2010-01-17 17:22     ` Stephen Hemminger
2010-01-15  2:22 ` Changli Gao
2010-01-15  6:19   ` Eric Dumazet
2010-01-15  6:39     ` Changli Gao
2010-01-15  6:57       ` Eric Dumazet
2010-01-15  8:49         ` David Miller
2010-01-15  9:20           ` Changli Gao
2010-01-15  9:26             ` David Miller
2010-01-21  7:04               ` Changli Gao
2010-01-15  9:45           ` David Miller
2010-01-15  8:50   ` David Miller
2010-01-15  9:05     ` Changli Gao
2010-01-15  6:27 ` Eric Dumazet
2010-01-16  2:26 ` Ben Hutchings
2010-01-21  7:54 ` Changli Gao
2010-01-21  9:16   ` Eric Dumazet
2010-01-28  6:04 ` Stephen Hemminger

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=20100114145633.4c2d4ac6@nehalam \
    --to=shemminger@vyatta.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.