netdev - Re: [RFC PATCH v2 08/10] net: sched: pfifo_fast use alf

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 15 Jul 2016 15:48:02 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Jesper Dangaard Brouer <brouer@...hat.com>, fw@...len.de,
	jhs@...atatu.com, eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [RFC PATCH v2 08/10] net: sched: pfifo_fast use alf_queue

On Fri, Jul 15, 2016 at 03:18:12PM -0700, John Fastabend wrote:
> 
> nolock (pfifo_fast)
> 1:  1440293 1421602 1409553 1393469 1424543
> 2:  1754890 1819292 1727948 1797711 1743427
> 4:  3282665 3344095 3315220 3332777 3348972
> 8:  2940079 1644450 2950777 2922085 2946310
> 12: 2042084 2610060 2857581 3493162 3104611
> 
> lock (pfifo_fast)
> 1:  1471479 1469142 1458825 1456788 1453952
> 2:  1746231 1749490 1753176 1753780 1755959
> 4:  1119626 1120515 1121478 1119220 1121115
> 8:  1001471  999308 1000318 1000776 1000384
> 12:  989269  992122  991590  986581  990430
> 
> So then if we just use the first test example because I'm being a
> bit lazy and don't want to calculate the avg/mean/whatever we get
> a pfifo_fast chart like,
> 
>       locked             nolock           diff
> ---------------------------------------------------
> 1     1471479            1440293          −  31186
> 2     1746231            1754890          +   8659
> 4     1119626            3282665          +2163039
> 8     1119626            2940079          +1820453
> 12     989269            2857581*         +1868312
...
> Also I'm going to take a look at Jesper's microbenchmark numbers but I
> think if I can convince myself that using skb_array helps or at least
> does no harm I might push to have this include with skb_array and then
> work on optimizing the ring type/kind/etc. as a follow up patch.
> Additionally it does seem to provide goodness on the pfifo_fast single
> queue case.

Agree. I think the pfifo_fast gains worth applying this patch set
as-is and work on further improvements in follow up.