From: Eric Dumazet <eric.dumazet@gmail.com>
To: Chetan Loke <chetanloke@gmail.com>
Cc: Bhavesh Davda <bhavesh@vmware.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"pv-drivers@vmware.com" <pv-drivers@vmware.com>,
"therbert@google.com" <therbert@google.com>
Subject: Re: [Pv-drivers] rps and pvdrivers
Date: Sat, 04 Sep 2010 16:31:04 +0200 [thread overview]
Message-ID: <1283610664.3402.34.camel@edumazet-laptop> (raw)
In-Reply-To: <AANLkTik+T8Sv1tEmy4PU0O-dOeymJLEkEd9QOYy7ZJzC@mail.gmail.com>
Le samedi 04 septembre 2010 à 10:02 -0400, Chetan Loke a écrit :
> On Sat, Sep 4, 2010 at 9:51 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > If packets have same rxhash, (same src IP, dst IP, src port, dst port),
> > they are directed on a single CPU, and this might explain you cannot
> > handle the load, RPS or not.
>
> I tried incrementing the src-macs from the load-generator. Or only the
> above 4-tuple entries are used?
>
MAC addresses are not used to compute rxhash
>
> >
> > cat /proc/net/softnet_stat
> >
>
> cat /proc/net/softnet_stat
> 0655cb87 006dd31b 00096a78 00000000 00000000 00000000 00000000
> 00000000 00000000 00000dbe
> 0042feec 00000000 0008ae33 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
>
> cat /proc/net/softnet_stat
> 065d444e 006e669d 00097565 00000000 00000000 00000000 00000000
> 00000000 00000000 00000dbe
> 0042ff8c 00000000 0008b83f 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
>
> cat /proc/net/softnet_stat
> 066a6fcf 006fefd9 000988c9 00000000 00000000 00000000 00000000
> 00000000 00000000 00000dbe
> 004300bd 00000000 0008c945 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
>
>
>
> > RPS is good to handle multiple flows, because it can distribute load on
> > several cpus. But with a single flow, I guess it might be not that
> > useful.
>
> For single flow if it doesn't improve performance that's fine. But it
> should atleast work as good as N-2(2.6.33).
>
Nope. Because if each packet goes through two cpus instead of one before
being queued to socket queue, you pay overhead and memory trafic between
these cpus.
This is the reason why RPS is not automatically switched on. It might be
slower on some workloads.
For UDP trafic, single flow, RPS is not a win, because UDP stack is
quite small.
next prev parent reply other threads:[~2010-09-04 14:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-03 19:49 rps and pvdrivers Chetan Loke
2010-09-03 21:05 ` [Pv-drivers] " Bhavesh Davda
2010-09-03 22:39 ` Chetan Loke
2010-09-04 6:51 ` Eric Dumazet
2010-09-04 7:00 ` Eric Dumazet
2010-09-04 13:38 ` Chetan Loke
2010-09-04 13:51 ` Eric Dumazet
2010-09-04 14:02 ` Chetan Loke
2010-09-04 14:31 ` Eric Dumazet [this message]
2010-09-04 15:27 ` Chetan Loke
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=1283610664.3402.34.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=bhavesh@vmware.com \
--cc=chetanloke@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pv-drivers@vmware.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