netdev - Re: skbuff truesize incorrect.

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:	Fri, 23 May 2014 08:44:01 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Bjørn Mork <bjorn@...k.no>,
	Jim Baxter <jim_baxter@...tor.com>
CC:	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, kamal@...onical.com, edumazet@...gle.com,
	mszeredi@...e.cz, fw@...len.de
Subject: Re: skbuff truesize incorrect.

On 05/23/2014 02:33 AM, Bjørn Mork wrote:
> Jim Baxter <jim_baxter@...tor.com> writes:
>
>>> I'll create and test a patch for the cdc_ncm host driver unless someone
>>> else wants to do that. I haven't really played with the gadget driver
>>> before, so I'd prefer if someone knowing it (Jim maybe?) could take care
>>> of it.  If not, then I can always make an attempt using dummy_hcd to
>>> test it.
>> I can create a patch for the host driver, I will issue the gadget patch
>> first to resolve any issues, the fix would be similar.
>
> Well, I couldn't help myself.  I just had to test it.  The attached
> patch works for me, briefly tested with an Ericsson H5321gw NCM device.
> I have no ideas about the performance impact as that modem is limited to
> 21 Mbps HSDPA.

If you are measuring performance with the likes of netperf, you should 
be able to get an idea of the performance effect from the change in 
service demand (CPU consumed per unit of work) even if the maximum 
throughput remains capped.

You can run a netperf TCP_STREAM test along the lines of:

netperf -H <otherguy> -c -C -t TCP_STREAM

and also

netperf -H <otherguy> -c -C -t TCP_RR

For extra added credit you can consider either multiple runs and 
post-processing, or adding a -i 30,3 to the command line to tell netperf 
to run at least three iterations, no more than thirty and it will try to 
achieve a 99% confidence that the reported means for throughput, local 
and remote CPU utilization are within +/- 2.5% of the actual mean.  You 
can narrow or widen that with a -I 99,<width>.  A width of 5% is what 
gives the +/- 2.5% (and/or demonstrates my lack of accurate statistics 
knowledge :) )

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