On Wed, Sep 6, 2017 at 12:51 AM, Stephen Hemminger <step...@networkplumber.org> wrote: > On Tue, 5 Sep 2017 15:35:50 -0700 > Petar Penkov <ppen...@google.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 <ppen...@google.com> >> Cc: Eric Dumazet <eduma...@google.com> >> Cc: Mahesh Bandewar <mahe...@google.com> >> Cc: Willem de Bruijn <will...@google.com> >> Cc: da...@davemloft.net >> Cc: ppen...@stanford.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.
