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

Date:   Thu, 15 Nov 2018 15:08:43 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Edward Cree <ecree@...arflare.com>,
        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 11/15/2018 02:45 PM, Edward Cree wrote:
> 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?

I do not want to hold on your patches, only to remind us that we add a lot of
features and stuff that might help in some cases only.

Another example is the IP early demux for UDP packets, which is clearly
a waste of time when the receiving socket is not a connected socket.