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.
