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] [day] [month] [year] [list]

Date:   Mon, 30 Jul 2018 17:38:55 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Saeed Mahameed <saeedm@...lanox.com>,
        Edward Cree <ecree@...arflare.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 Wed, Jul 11, 2018 at 11:06 PM, Jesper Dangaard Brouer
<brouer@...hat.com> wrote:
> On Wed, 11 Jul 2018 19:05:20 +0000
> Saeed Mahameed <saeedm@...lanox.com> wrote:
>
>> On Wed, 2018-07-11 at 17:01 +0200, Jesper Dangaard Brouer wrote:
>> > Only driver sfc actually uses this, but I don't have this NIC, so I
>> > tested this on mlx5, with my own changes to make it use
>> > netif_receive_skb_list(),
>> > but I'm not ready to upstream the mlx5 driver change yet.
>>
>>
>> Thanks Jesper for sharing this, should we look forward to those patches
>> or do you want us to implement them ?
>
> Well, I would prefer you to implement those.  I just did a quick
> implementation (its trivially easy) so I have something to benchmark
> with.  The performance boost is quite impressive!
>
> 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().
> And your driver uses napi_gro_receive().  This sort-of disables GRO for
> your driver, which is not a choice I can make.  Interestingly I get

But we can apply such patch on the mlx5 code path which comes
into play when GRO is disabled, right? or there's just one code path
there. Can you send your patch as RFC to the list for the purpose of
experimentation?

> around the same netperf TCP_STREAM performance.  I assume we can get
> even better perf if we "listify" napi_gro_receive.