netdev - Re: [PATCH net-next] net: dummy: make use of multi-queues

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] [day] [month] [year] [list]

Message-ID: <5333F3F4.3040708@redhat.com>
Date:	Thu, 27 Mar 2014 10:48:36 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	davem@...emloft.net, netdev@...r.kernel.org,
	Jesper Dangaard Brouer <brouer@...hat.com>
Subject: Re: [PATCH net-next] net: dummy: make use of multi-queues

On 03/27/2014 03:51 AM, Eric Dumazet wrote:
> On Thu, 2014-03-27 at 01:37 +0100, Daniel Borkmann wrote:
>> Quite often it can be useful to just use the dummy device as a blackhole
>> sink for skbs, e.g. for packet sockets or pktgen tests. Therefore, make
>> use of multiqueues, so that we can simulate for that. trafgen mmap/TX_RING
>> example against dummy device with config foo: { fill(0xff, 64) } results
>> in the following performance improvements on an ordinary Core i7/2.80GHz
>> as we don't need to take a single queue/lock anymore:
>>
>> Before:
>>
>>   Performance counter stats for 'trafgen -i foo -o du0 -n100000000' (10 runs):
>>
>>     160,975,944,159 instructions:k            #    0.55  insns per cycle          ( +-  0.09% )
>>     293,319,390,278 cycles:k                  #    0.000 GHz                      ( +-  0.35% )
>>         192,501,104 branch-misses:k                                               ( +-  1.63% )
>>                 831 context-switches:k                                            ( +-  9.18% )
>>                   7 cpu-migrations:k                                              ( +-  7.40% )
>>              69,382 cache-misses:k            #    0.010 % of all cache refs      ( +-  2.18% )
>>         671,552,021 cache-references:k                                            ( +-  1.29% )
>>
>>        22.856401569 seconds time elapsed                                          ( +-  0.33% )
>>
>> After:
>>
>>   Performance counter stats for 'trafgen -i foo -o du0 -n100000000' (10 runs):
>>
>>     138,669,108,882 instructions:k            #    0.92  insns per cycle          ( +-  0.02% )
>>     151,222,621,155 cycles:k                  #    0.000 GHz                      ( +-  0.11% )
>>          57,667,395 branch-misses:k                                               ( +-  6.15% )
>>                 400 context-switches:k                                            ( +-  2.73% )
>>                   6 cpu-migrations:k                                              ( +-  7.51% )
>>              67,414 cache-misses:k            #    0.075 % of all cache refs      ( +-  1.64% )
>>          90,479,875 cache-references:k                                            ( +-  0.75% )
>>
>>        12.080331543 seconds time elapsed                                          ( +-  0.13% )
>
>
>
> Its a LLTX device, so it looks there is no bottleneck in this driver,
> but in the caller ;)

Ohh, I see the issue, thanks for pointing this out Eric.

I'll fix this up differently. ;-)

> If you need many channels, you can setup as many dummy devices you want.
--
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