linux-kernel - Re: [PATCH net-next 2/2] net: core: increase the default size of GRO

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: <1eaac2e1f1d65194a4a39232d7e45870@dlink.ru>
Date:   Fri, 11 Oct 2019 10:23:37 +0300
From:   Alexander Lobakin <alobakin@...nk.ru>
To:     Edward Cree <ecree@...arflare.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Petr Machata <petrm@...lanox.com>,
        Sabrina Dubroca <sd@...asysnail.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] net: core: increase the default size of
 GRO_NORMAL skb lists to flush

Hi Edward,

Edward Cree wrote 10.10.2019 21:16:
> On 10/10/2019 15:42, Alexander Lobakin wrote:
>> Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL
>> skbs") have introduced a sysctl variable gro_normal_batch for defining
>> a limit for listified Rx of GRO_NORMAL skbs. The initial value of 8 is
>> purely arbitrary and has been chosen, I believe, as a minimal safe
>> default.
> 8 was chosen by performance tests on my setup with v1 of that patch;
>  see https://www.spinics.net/lists/netdev/msg585001.html .
> Sorry for not including that info in the final version of the patch.
> While I didn't re-do tests on varying gro_normal_batch on the final
>  version, I think changing it needs more evidence than just "we tested
>  it; it's better".  In particular, increasing the batch size should be
>  accompanied by demonstration that latency isn't increased in e.g. a
>  multi-stream ping-pong test.
> 
>> However, several tests show that it's rather suboptimal and doesn't
>> allow to take a full advantage of listified processing. The best and
>> the most balanced results have been achieved with a batches of 16 skbs
>> per flush.
>> So double the default value to give a yet another boost for Rx path.
> 
>> It remains configurable via sysctl anyway, so may be fine-tuned for
>> each hardware.
> I see this as a reason to leave the default as it is; the combination
>  of your tests and mine have established that the optimal size does
>  vary (I found 16 to be 2% slower than 8 with my setup), so any
>  tweaking of the default is likely only worthwhile if we have data
>  over lots of different hardware combinations.

Agree, if you've got slower results on 16, we must leave the default
value, as it seems to be VERY hardware- and driver- dependent.
So, patch 2/2 is not actual any more (I supposed that it would likely
go away before sending this series).

>> Signed-off-by: Alexander Lobakin <alobakin@...nk.ru>
>> ---
>>  net/core/dev.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index a33f56b439ce..4f60444bb766 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4189,7 +4189,7 @@ int dev_weight_tx_bias __read_mostly = 1;  /* 
>> bias for output_queue quota */
>>  int dev_rx_weight __read_mostly = 64;
>>  int dev_tx_weight __read_mostly = 64;
>>  /* Maximum number of GRO_NORMAL skbs to batch up for list-RX */
>> -int gro_normal_batch __read_mostly = 8;
>> +int gro_normal_batch __read_mostly = 16;
>> 
>>  /* Called with irq disabled */
>>  static inline void ____napi_schedule(struct softnet_data *sd,

Regards,
ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ