On Mon, Jan 25, 2016 at 1:15 PM, Taylor R Campbell
<campbell+netbsd-tech-k...@mumble.net> wrote:
> Date: Wed, 20 Jan 2016 17:03:09 +0900
> From: Ryota Ozaki <ozak...@netbsd.org>
>
> I measured several cases of softint-based if_input implementation
> and other implementations including vanilla and polling-based
> packet processing (POC).
>
> Here are the results of the measurements (TL;TR):
> https://gist.github.com/ozaki-r/975b06216a54a084debc
>
> I'm having a little bit of a hard time following these graphs. Can
> you explain how I should read them? E.g., what does
>
> polling-rx w/o ip_pktq
>
> RX/TX = 148809 / 148809 pps, 100M / 100Mbps |######### 100.0%
> RX/TX = 253096 / 297597 pps, 170M / 200Mbps |################# 85.0%
>
> mean?
Oh, sorry for my laziness. Let me explain how to read the results.
The traffic generator records how many packets it sends and receives
to/from a DUT and calculates traffic rates in pps and Mbps.
> RX/TX = 253096 / 297597 pps, 170M / 200Mbps |################# 85.0%
^ received packet rate in pps
^ sent packet rate in pps
^ received packet rate in Mbps
^ sent packet rate in Mbps
'####' bar indicates the received packet rate and a percentage
at the rightmost indicates a ratio of received packets / sent packets.
>
> Small concern about your no-ip_pktq patch: with it, you acquire and
> release softnet_lock for every packet, whereas without it, the ip_pktq
> softintr handler acquires softnet_lock once, processes all packets in
> the pcq in a batch, and then releases softnet_lock. Maybe that's not
> an issue since pcq_get already involves atomics, but it stuck out at
> me a little bit.
Oops, I should move softnet_lock in ipintr in the patch. I guess
it doesn't affect the results of the measurement because it never
cause contentions in the measurements (only CPU#0 is used).
Anyway we should finally remove it for parallel processing...
Thanks,
ozaki-r
