netdev - Re: [net-next PATCH] net: ipv4: fix listify ip_rcv

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]

Message-ID: <3d08d6ae-a4cc-f9ad-f752-ba66ca13240b@solarflare.com>
Date:   Fri, 13 Jul 2018 15:19:40 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Or Gerlitz <gerlitz.or@...il.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>
CC:     Saeed Mahameed <saeedm@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [net-next PATCH] net: ipv4: fix listify ip_rcv_finish in case of
 forwarding

On 12/07/18 21:10, Or Gerlitz wrote:
> On Wed, Jul 11, 2018 at 11:06 PM, Jesper Dangaard Brouer
> <brouer@...hat.com> wrote:
>> One reason I didn't "just" send a patch, is that Edward so-fare only
>> implemented netif_receive_skb_list() and not napi_gro_receive_list().
> sfc does't support gro?! doesn't make sense.. Edward?
sfc has a flag EFX_RX_PKT_TCP set according to bits in the RX event, we
 call napi_{get,gro}_frags() (via efx_rx_packet_gro()) for TCP packets and
 netif_receive_skb() (or now the list handling) (via efx_rx_deliver()) for
 non-TCP packets.  So we avoid the GRO overhead for non-TCP workloads.

> Same TCP performance
>
> with GRO and no rx-batching
>
> or
>
> without GRO and yes rx-batching
>
> is by far not intuitive result
I'm also surprised by this.  If I can find the time I'll try to do similar
 experiments on sfc.
Jesper, are the CPU utilisations similar in both cases?  You're sure your
 stream isn't TX-limited?

-Ed