All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.com \
    --cc=netdev@vger.kernel.org \
    --cc=seshajay@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 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.