netdev - Re: [PATCH][net-next][v2] net: limit each hash list length to MAX_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: <4df439f1-d80c-a2ff-d1ac-d5475694a59e@gmail.com>
Date:   Sat, 7 Jul 2018 17:22:01 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     David Miller <davem@...emloft.net>, lirongqing@...du.com
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH][net-next][v2] net: limit each hash list length to
 MAX_GRO_SKBS



On 07/05/2018 03:20 AM, David Miller wrote:
> From: Li RongQing <lirongqing@...du.com>
> Date: Thu,  5 Jul 2018 14:34:32 +0800
> 
>> After commit 07d78363dcff ("net: Convert NAPI gro list into a small hash
>> table.")' there is 8 hash buckets, which allows more flows to be held for
>> merging.  but MAX_GRO_SKBS, the total held skb for merging, is 8 skb still,
>> limit the hash table performance.
>>
>> keep MAX_GRO_SKBS as 8 skb, but limit each hash list length to 8 skb, not
>> the total 8 skb
>>
>> Signed-off-by: Li RongQing <lirongqing@...du.com>
> 
> Applied, thanks.
> 

Maybe gro_count should be replaced by a bitmask, so that we can speed up
napi_gro_flush(), since it now has to use 3 cache lines (gro_hash[] size is 192 bytes)