netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Franco Fichtner <franco@lastsummer.de>
To: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Changli Gao <xiaosuo@gmail.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next-2.6] rps: consistent rxhash
Date: Wed, 21 Apr 2010 11:29:55 +0200	[thread overview]
Message-ID: <4BCEC593.4000007@lastsummer.de> (raw)
In-Reply-To: <i2q65634d661004200809ydba56c35g785ba51900c379f7@mail.gmail.com>

Tom Herbert wrote:
>> I thought about this for some time...
>>
>> Do we really need the port numbers here at all? A simple
>> addr1^addr2 can provide a good enough pointer for
>> distribution amongst CPUs.
>>
> 
> What about a server behind a TCP proxy?  Also, need to minimize
> collisions for RPS to be effective

What about routers? What about loopback? This all boils down to
the same issue of obscuring IP data by "magical" means and then
reattaching functionality by reaching for upper layer information.
It is necessary in some cases, but it can cripple performance
for other cases.

The interesting thing is you don't need to deal with collisions
while distributing amonst cpus at all. You just need to make sure
the distribution algorithm keeps every single flow attached to
the correct cpu.

All of the actual flow hashing, tracking and whatever else the
traffic needs to go through can be done locally by cpu x which
helps a lot with load distribution and cache issues in mind. It
also helps locking because there is no global flow lookup table.
Oh, and it also reduces collisions with every cpu you add for
receiving.

I work with a lot of plain office and ISP traffic in mind daily,
so please don't misunderstand my motivation here. I'd hate to
see poor performance in scenarios in which there is a lot of
potential improvement.


Franco

  reply	other threads:[~2010-04-21  9:29 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16  5:47 [PATCH v5] rfs: Receive Flow Steering Tom Herbert
2010-04-16  6:33 ` David Miller
2010-04-16  6:56   ` Eric Dumazet
2010-04-16  7:18     ` Eric Dumazet
2010-04-16  7:26       ` David Miller
2010-04-16  7:48         ` Eric Dumazet
2010-04-17  7:52           ` [PATCH net-next-2.6] rps: rps_sock_flow_table is mostly read Eric Dumazet
2010-04-17  7:57             ` David Miller
2010-04-16 15:35     ` [PATCH v5] rfs: Receive Flow Steering Tom Herbert
2010-04-16 18:15       ` Eric Dumazet
2010-04-16 18:35     ` Tom Herbert
2010-04-16 18:53       ` Eric Dumazet
2010-04-16 20:42         ` Tom Herbert
2010-04-16 21:12           ` Eric Dumazet
2010-04-16 21:25             ` Eric Dumazet
2010-04-17 16:10             ` Eric Dumazet
2010-04-17 17:38               ` Tom Herbert
2010-04-18  0:06                 ` Changli Gao
2010-04-18 11:06                   ` Franco Fichtner
2010-04-19 20:09               ` David Miller
2010-04-19 20:23                 ` David Miller
2010-04-19 20:32                   ` Eric Dumazet
2010-04-19 21:19                     ` David Miller
2010-04-26  8:41                       ` Eric Dumazet
2010-04-27 21:59                         ` David Miller
2010-04-27 22:08                           ` Eric Dumazet
2010-04-27 22:10                             ` David Miller
2010-04-19 23:38                     ` Changli Gao
2010-04-20  5:59                       ` Eric Dumazet
2010-04-20  7:56                         ` [PATCH net-next-2.6] rps: consistent rxhash Eric Dumazet
2010-04-20  8:18                           ` David Miller
2010-04-20 12:48                           ` Franco Fichtner
2010-04-20 13:16                             ` Eric Dumazet
2010-04-20 14:03                               ` Franco Fichtner
2010-04-20 14:57                                 ` Eric Dumazet
2010-04-20 21:41                                   ` David Miller
2010-04-20 23:35                                     ` Changli Gao
2010-04-20 23:38                                       ` David Miller
2010-04-21 19:12                                     ` Tom Herbert
2010-04-23 20:44                                       ` David Miller
2010-05-06  8:06                                       ` David Miller
2010-05-06 14:45                                         ` Tom Herbert
2010-04-20 15:09                             ` Tom Herbert
2010-04-21  9:29                               ` Franco Fichtner [this message]
2010-04-21  9:39                                 ` Eric Dumazet
2010-04-21 11:06                                   ` Franco Fichtner
2010-04-21 11:16                                     ` Eric Dumazet
2010-04-20 15:04                         ` [PATCH v5] rfs: Receive Flow Steering Tom Herbert
2010-04-20 15:39                           ` Eric Dumazet
2010-04-16 19:37   ` Eric Dumazet
2010-04-16 22:49     ` David Miller
2010-04-16 22:53       ` David Miller
2010-04-16 22:57         ` David Miller
2010-04-17  0:22           ` Tom Herbert
2010-04-17  0:58             ` David Miller
2010-04-16 11:57 ` Andi Kleen
2010-04-16 13:32   ` jamal
2010-04-16 13:42     ` Andi Kleen
2010-04-16 14:05       ` jamal
2010-04-16 15:28         ` Andi Kleen

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=4BCEC593.4000007@lastsummer.de \
    --to=franco@lastsummer.de \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=therbert@google.com \
    --cc=xiaosuo@gmail.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).