[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d3aaaca4-41a6-d8fb-5156-9c8e7921c04a@gmail.com>
Date: Fri, 5 Apr 2019 04:00:20 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Florian Westphal <fw@...len.de>,
Toke Høiland-Jørgensen
<toke@...hat.com>
Cc: Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
Felix Fietkau <nbd@....name>,
Rafał Miłecki <zajec5@...il.com>,
Toshiaki Makita <toshiaki.makita1@...il.com>,
netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Stefano Brivio <sbrivio@...hat.com>,
Sabrina Dubroca <sd@...asysnail.net>,
David Ahern <dsahern@...il.com>, Jo-Philipp Wich <jo@...n.io>,
Koen Vandeputte <koen.vandeputte@...ntric.com>
Subject: Re: NAT performance regression caused by vlan GRO support
On 04/05/2019 03:51 AM, Florian Westphal wrote:
> Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>> As a first approximation, maybe just:
>>
>> if (!has_hardware_cksum_offload(netdev) && link_rate(netdev) <= 1Gbps)
>> disable_gro();
>
> I don't think its a good idea. For local delivery case, there is no
> way to avoid the checksum cost, so might as well have GRO enabled.
>
We might add a sysctl or a way to tell GRO layer :
Do not attempt checksumming if forwarding is enabled on the host.
Basically GRO if NIC has provided checksum offload.
Powered by blists - more mailing lists