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: <CO2PR11MB0088949623FA99ED86D33205972D0@CO2PR11MB0088.namprd11.prod.outlook.com>
Date:	Thu, 23 Jun 2016 04:17:18 +0000
From:	Yuval Mintz <Yuval.Mintz@...gic.com>
To:	Alexander Duyck <alexander.duyck@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	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

> Then again, if you're basically saying every HW-assisted offload on
> receive should be done under LRO flag, what would be the use case
> where a GRO-assisted offload would help?

> I.e., afaik LRO is superior to GRO in `brute force' -
> it creates better packed packets and utilizes memory better
> [with all the obvious cons such as inability for defragmentation].
> So if you'd have the choice of having an adpater perform 'classic'
> LRO aggregation or something that resembles a GRO packet,
> what would be the gain from doing the latter?

Just to relate to bnx2x/qede differences in current implementation -
when this GRO hw-offload was added to bnx2x, it has already
supported classical LRO, and due to above statement whenever LRO
was set driver aggregated incoming traffic as classic LRO.
I agree that in hindsight the lack of distinction between sw/hw GRO
was hurting us.

qede isn't implementing LRO, so we could easily mark this feature
under LRO there - but question is, given that the adapter can support
LRO, if we're going to suffer from all the shotrages that arise from
putting this feature under LRO, why should we bother?

You can argue that we might need a new feature bit for control
over such a feature; If we don't do that, is there any gain in all of this?