From: Rick Jones <rick.jones2@hp•com>
To: ajay seshadri <seshajay@gmail•com>
Cc: netdev <netdev@vger•kernel.org>
Subject: Re: Fwd: UDP/IPv6 performance issue
Date: Tue, 10 Dec 2013 13:30:49 -0800 [thread overview]
Message-ID: <52A78809.4020103@hp.com> (raw)
In-Reply-To: <CAGA2gK7tjQZ6sq1qqTua_J0uY47Dq7h-vWR=c_LQReq3Rwc=_Q@mail.gmail.com>
On 12/10/2013 11:32 AM, ajay seshadri wrote:
> On Tue, Dec 10, 2013 at 12:24 PM, Rick Jones <rick.jones2@hp•com> wrote:
>>> If you want to compare the "fundamental" path length difference between
>>> IPv4 and IPv6, without any concerns about stateless offloads like CKO or
>>> GRO et al, you could use something like a single-byte netperf TCP_RR test.
>>>
>>> netperf -c -C -H <remote> -t TCP_RR
>>
>> Or UDP_RR, since that is your usage case...
>
> I am not sure what you mean by '"fundamental" path length difference',
> can you please elaborate.
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.
When I talk about a per-byte cost that is usually something like
computing the checksum, or copying data to/from the kernel.
A per-packet cost would be going up/down the protocol stack. TSO, GSO,
UFO, and their receive side analogues would be things that reduced
per-packet costs, but only when one is sending a lot of data at one time.
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.
> For now i use:
> ./netperf -t UDP_STREAM -H <remote> -l 60 -- -m 1450
> I am trying to find the maximum throughput I can get at 1500 MTU for
> UDP packets (IPv4 / IPv6) without using offloading.
I presume you are looking at the receive throughput and not the reported
send side throughput right?
happy benchmarking,
rick jones
next prev parent reply other threads:[~2013-12-10 21:30 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 [this message]
2013-12-10 22:25 ` ajay seshadri
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=52A78809.4020103@hp.com \
--to=rick.jones2@hp$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=seshajay@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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