From: Stephen Hemminger <shemminger@vyatta.com>
To: Tom Herbert <therbert@google.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
eric.dumazet@gmail.com, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v4] rfs: Receive Flow Steering
Date: Mon, 12 Apr 2010 17:12:05 -0700 [thread overview]
Message-ID: <20100412171205.561a1aec@nehalam> (raw)
In-Reply-To: <alpine.DEB.1.00.1004121651460.31468@pokey.mtv.corp.google.com>
On Mon, 12 Apr 2010 17:03:39 -0700 (PDT)
Tom Herbert <therbert@google.com> wrote:
> The basic idea of RFS is that when an application calls recvmsg
> (or sendmsg) the application's running CPU is stored in a hash
> table that is indexed by the connection's rxhash which is stored in
> the socket structure. The rxhash is passed in skb's received on
> the connection from netif_receive_skb. For each received packet,
> the associated rxhash is used to look up the CPU in the hash table,
> if a valid CPU is set then the packet is steered to that CPU using
> the RPS mechanisms.
There are two sometimes conflicting models:
One model is to have the flow's be dispersed and let the scheduler
be smarter about running the applications on the right CPU's where
the packets arrive.
The other is to have the flows redirected to the CPU where the application
previously ran which is what RFS does.
For benchmarks and private fixed configuration systems it is tempting
to just nail everything down: i.e. use hard SMP affinity, for hardware, processes,
and flows. But this is the wrong solution for general purpose systems with
varying workloads and requirements. How well does RFS really work when
applications, processes, and sockets come and go or get migrated among
CPU's by the scheduler? My concern is this is overlapping scheduler
design and might be a step backwards.
--
next prev parent reply other threads:[~2010-04-13 0:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-13 0:03 [PATCH v4] rfs: Receive Flow Steering Tom Herbert
2010-04-13 0:12 ` Stephen Hemminger [this message]
2010-04-16 15:51 ` Tom Herbert
2010-04-16 17:33 ` Rick Jones
2010-04-16 17:59 ` Paul Turner
2010-04-16 18:32 ` Rick Jones
2010-04-13 8:45 ` Eric Dumazet
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=20100412171205.561a1aec@nehalam \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=mingo@elte.hu \
--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 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).