netdev - Re: Fwd: UDP/IPv6 performance issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Dec 2013 13:30:49 -0800
From:	Rick Jones <rick.jones2@...com>
To:	ajay seshadri <seshajay@...il.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: Fwd: UDP/IPv6 performance issue

On 12/10/2013 11:32 AM, ajay seshadri wrote:
> On Tue, Dec 10, 2013 at 12:24 PM, Rick Jones <rick.jones2@...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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html