Re: RFC: softint-based if_input

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Mon, Jan 25, 2016 at 1:15 PM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>    Date: Wed, 20 Jan 2016 17:03:09 +0900
>    From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>
>    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