From: Rick Jones <rick.jones2@hp.com>
To: Tom Herbert <tom@herbertland.com>,
davem@davemloft.net, netdev@vger.kernel.org,
sramamur@linux.vnet.ibm.com
Subject: Re: [PATCH RFC net-next] vxlan: GRO support at tunnel layer
Date: Fri, 26 Jun 2015 17:46:02 -0700 [thread overview]
Message-ID: <558DF24A.1040504@hp.com> (raw)
In-Reply-To: <1435360189-641007-1-git-send-email-tom@herbertland.com>
On 06/26/2015 04:09 PM, Tom Herbert wrote:
> Add calls to gro_cells infrastructure to do GRO when receiving on a tunnel.
>
> Testing:
>
> Ran 200 netperf TCP_STREAM instance
>
> - With fix (GRO enabled on VXLAN interface)
>
> Verify GRO is happening.
>
> 9084 MBps tput
> 3.44% CPU utilization
>
> - Without fix (GRO disabled on VXLAN interface)
>
> Verified no GRO is happening.
>
> 9084 MBps tput
> 5.54% CPU utilization
This has been an area of interest so:
Tested-by: Rick Jones <rick.jones2@hp.com>
Some single-stream results between two otherwise identical systems with
82599ES NICs in them, one running a 4.1.0-rc1+ kernel from a davem tree
from a while ago, the other running 4.1.0+ from a davem tree pulled
yesterday upon which I've applied the patch.
Netperf command used:
netperf -l 30 -H <IP> -t TCP_MAERTS -c -- -O
throughput,local_cpu_util,local_cpu_peak_util,local_cpu_peak_id,local_sd
First, inbound to the unpatched system from the patched:
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.0.21 () port 0 AF_INET : demo
Throughput Local Local Local Local
CPU Peak Peak Service
Util Per CPU Per CPU Demand
% Util % ID
5487.42 6.01 99.83 0 2.872
5580.83 6.20 99.16 0 2.911
5445.52 5.68 98.92 0 2.734
5653.36 6.24 99.80 0 2.891
5187.56 5.66 97.41 0 2.858
Second, inbound to the patched system from the unpatched:
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.0.22 () port 0 AF_INET : demo
Throughput Local Local Local Local
CPU Peak Peak Service
Util Per CPU Per CPU Demand
% Util % ID
6933.29 3.19 93.67 3 1.208
7031.35 3.34 95.08 3 1.244
7006.28 3.27 94.55 3 1.223
6948.62 3.09 93.20 3 1.165
7007.80 3.22 94.34 3 1.206
Comparing the service demands shows a > 50% reduction in overhead.
next prev parent reply other threads:[~2015-06-27 0:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 23:09 [PATCH RFC net-next] vxlan: GRO support at tunnel layer Tom Herbert
2015-06-27 0:46 ` Rick Jones [this message]
2015-06-28 17:20 ` Ramu Ramamurthy
2015-06-28 21:31 ` Tom Herbert
2015-06-29 15:40 ` Rick Jones
2015-06-29 15:45 ` Rick Jones
2015-06-29 20:04 ` Rick Jones
2015-06-30 1:06 ` Jesse Gross
2015-06-30 5:06 ` 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=558DF24A.1040504@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sramamur@linux.vnet.ibm.com \
--cc=tom@herbertland.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.