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]
Message-ID: <1395888662.12610.278.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 26 Mar 2014 19:51:02 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Daniel Borkmann <dborkman@...hat.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 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 ;)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ