From: ajay seshadri <seshajay@gmail.com>
To: Rick Jones <rick.jones2@hp.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: Fwd: UDP/IPv6 performance issue
Date: Tue, 10 Dec 2013 17:25:52 -0500 [thread overview]
Message-ID: <CAGA2gK6-9QednGxrPr_zrTHYm4W6t7yrrBOSNitujTMLibuOww@mail.gmail.com> (raw)
In-Reply-To: <52A78809.4020103@hp.com>
Hi Rick,
On Tue, Dec 10, 2013 at 4:30 PM, Rick Jones <rick.jones2@hp.com> wrote:
> I mean how many instructions/cycles it takes to send/receive a single
> packet, where all the costs are the per-packet costs and the per-byte costs
> are kept at a minimum. And also where the stateless offloads won't matter.
> That way whether a stateless offload is enabled for one protocol or another
> is essentially a don't care.
Given below are the results for tests you recommended:
IPv6:
MIGRATED UDP REQUEST/RESPONSE TEST from ::0 (::) port 0 AF_INET6 to
1111::80 () port 0 AF_INET6 : first burst 0
Local /Remote
Socket Size Request Resp. Elapsed Trans. CPU CPU
S.dem S.dem
Send Recv Size Size Time Rate
local remote local remote
bytes bytes bytes bytes secs. per sec % S
% S us/Tr us/Tr
10485760 10485760 1 1 10.00 16977.61 5.12 5.46
24.138 25.721
10485760 10485760
IPv4:
MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0
AF_INET to 192.168.31.80 () port 0 AF_INET : first burst 0
Local /Remote
Socket Size Request Resp. Elapsed Trans. CPU
CPU S.dem S.dem
Send Recv Size Size Time Rate
local remote local remote
bytes bytes bytes bytes secs. per sec %
S % S us/Tr us/Tr
10485760 10485760 1 1 10.00 20414.38 5.24
4.70 20.522 18.417
10485760 10485760
The transaction rate for IPv6 is less.
> So, single-byte _RR since it is sending only one byte at a time will
> effectively "bypass" the offloads. I use it as something of a proxy for
> those things that aren't blasting great quantities of data.
With no segmentation offload, I was treating the CPU as a known
bottleneck in both the cases and trying to do an apples to apples
comparison between UDP IPv4 and IPv6 performance. As we take a 15 -
20% performance hit for IPv6, I was trying to understand why the ipv6
route cache gc functions showed up in the profile, which was a bit
surprising.
> I presume you are looking at the receive throughput and not the reported
> send side throughput right?
I am looking at the bytes received. In fact the two are identical as
the network no longer is the bottleneck and we are pegged by the CPU
on the sender for 1500 byte packets.
Thanks,
Ajay
next prev parent reply other threads:[~2013-12-10 22:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGA2gK6rf8E7cCO=RwbdFAt2ucfxUbCjqhVoga9cnHrEKxcp9g@mail.gmail.com>
2013-12-10 16:19 ` Fwd: UDP/IPv6 performance issue ajay seshadri
2013-12-10 17:05 ` Rick Jones
2013-12-10 17:24 ` Rick Jones
2013-12-10 19:32 ` ajay seshadri
2013-12-10 21:30 ` Rick Jones
2013-12-10 22:25 ` ajay seshadri [this message]
2013-12-10 17:12 ` Hannes Frederic Sowa
2013-12-10 19:46 ` ajay seshadri
2013-12-10 22:11 ` ajay seshadri
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=CAGA2gK6-9QednGxrPr_zrTHYm4W6t7yrrBOSNitujTMLibuOww@mail.gmail.com \
--to=seshajay@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.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).