netdev - Re: [PATCH net-next RFC 1/2] tun: enable NAPI for TUN/TAP driver

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]

Date:   Wed, 6 Sep 2017 11:18:58 +0200
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Petar Penkov <ppenkov@...gle.com>,
        Network Development <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Mahesh Bandewar <maheshb@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        David Miller <davem@...emloft.net>, ppenkov@...nford.edu
Subject: Re: [PATCH net-next RFC 1/2] tun: enable NAPI for TUN/TAP driver

On Wed, Sep 6, 2017 at 12:51 AM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Tue,  5 Sep 2017 15:35:50 -0700
> Petar Penkov <ppenkov@...gle.com> wrote:
>
>> Changes TUN driver to use napi_gro_receive() upon receiving packets
>> rather than netif_rx_ni(). Adds flag CONFIG_TUN_NAPI that enables
>> these changes and operation is not affected if the flag is disabled.
>> SKBs are constructed upon packet arrival and are queued to be
>> processed later.
>>
>> The new path was evaluated with a benchmark with the following setup:
>> Open two tap devices and a receiver thread that reads in a loop for
>> each device. Start one sender thread and pin all threads to different
>> CPUs. Send 1M minimum UDP packets to each device and measure sending
>> time for each of the sending methods:
>>       napi_gro_receive():     4.90s
>>       netif_rx_ni():          4.90s
>>       netif_receive_skb():    7.20s
>>
>> Signed-off-by: Petar Penkov <ppenkov@...gle.com>
>> Cc: Eric Dumazet <edumazet@...gle.com>
>> Cc: Mahesh Bandewar <maheshb@...gle.com>
>> Cc: Willem de Bruijn <willemb@...gle.com>
>> Cc: davem@...emloft.net
>> Cc: ppenkov@...nford.edu
>
> Why is this optional? It adds two code paths both of which need
> to be tested.

If the napi_gro_receive path is no more expensive than netif_receive_skb,
as the evaluation indicates, then it is a good candidate to replace that.

The napi_gro_frags path is purely for code coverage. There is no benefit
to applications to treat data copied from userspace as if it consists of raw
pages of data.