netdev - Re: [PATCH v3 net-next 0/4] net: batched receive in GRO path

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: <1098391b-1b2e-3d75-f5ab-8f592843a955@solarflare.com>
Date:   Thu, 15 Nov 2018 22:45:45 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        <linux-net-drivers@...arflare.com>, <davem@...emloft.net>
CC:     <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 net-next 0/4] net: batched receive in GRO path

On 15/11/18 22:01, Eric Dumazet wrote:
> On 11/15/2018 01:45 PM, Edward Cree wrote:
>> If napi->poll() is only handling one packet, surely GRO can't do anything
>>  useful either?  (AIUI at the end of the poll the GRO lists get flushed.)
> That is my point.
>
> Adding yet another layer that will add no gain but add more waste of cpu cycles.
>
> In fact I know many people disabling GRO in some cases because it adds ~5% penalty
> for traffic that is not aggregated.
Does there maybe need to be an (ethtool -K) option to disable batch receive,
 then, for this kind of user?

>>  Is it maybe a sign that you're just spreading over too many queues??
> Not really. You also want to be able to receive more traffic if the need comes.
Oh I see, this is about using less CPU when not maxed out, rather than
 increasing the maximum performance.
I did see a 6% RXCPU usage increase in the "TCP RR, GRO on" test.  (Before=
 188.7%, after=200%, Welch p<0.001, Cohen's d=6.2.)  I'll try adding a "skip
 batching for short lists" and retest, see if that improves matters.