netdev - Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

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: <CAKgT0Ud3RQjLFJZKX-MGphbdNi83c9q5QnaU4dV3X0WHGD-vLA@mail.gmail.com>
Date:	Fri, 24 Jun 2016 09:44:24 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Yuval Mintz <Yuval.Mintz@...gic.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Rick Jones <rick.jones2@....com>,
	Manish Chopra <manish.chopra@...gic.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Ariel Elior <Ariel.Elior@...gic.com>,
	Tom Herbert <tom@...bertland.com>,
	Hannes Frederic Sowa <hannes@...hat.com>
Subject: Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Thu, Jun 23, 2016 at 10:20 PM, Yuval Mintz <Yuval.Mintz@...gic.com> wrote:
>>We already know of one firmware bug you guys have which makes
>>it clear that the bnx2x is not doing hardware assisted GRO it is doing
>>something else since it performs much worse than GRO if the MSS is
>>less than what it would be based on the MTU.
>
> It's a bit nitpicky, isn't it? Claiming this flaw means it's not GRO.
> I.e., you obviously wouldn't have claimed it beacme GRO if it
> was fixed.
>
> Not saying it makes a lot of difference, though.

The fact is LRO and GRO are two separate things.  Even without the bug
in the firmware I would still be saying the are two very different
things.  Your GRO implementation only supports a subset of the
features that GRO has in the hardware.  The way the kernel has
implemented things we should keep GRO and GSO symmetric if at all
possible.  There aren't currently any GSO hardware offloads so there
probably shouldn't be any GRO hardware offloads.  On the other hand
devices do support TSO hardware offloads so it would make sense to
match that up and support LRO as the hardware equivalent of GRO.

Anyway that is my opinion.  It may be nitpicky but I don't fee that we
should be re-purposing feature bits that were meant to be software
features to represent hardware ones.

- Alex