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: <058fd87e-4dbe-f80e-0606-508956f339a7@solarflare.com>
Date:	Fri, 24 Jun 2016 14:09:11 +0100
From:	Edward Cree <ecree@...arflare.com>
To:	Alexander Duyck <alexander.duyck@...il.com>,
	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>,
	Bert Kenward <bkenward@...arflare.com>
Subject: Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On 23/06/16 18:07, Alexander Duyck wrote:
> I would prefer to see us extend LRO to support "close enough GRO"
> instead of have us extend GRO to also include LRO.
This reminds me of something I've been meaning to bring up (sorry for
slightly OT, but it might turn out relevant after all).
In sfc we have an (out-of-tree and likely staying that way) LRO that's
entirely in software.  The only reason it exists is for users who want
the 'permissive' merging behaviour of LRO, i.e. they don't need the
guarantees of reversibility and by merging more stuff they can get
slightly higher performance.
I wonder if it would be a good idea for the GRO implementation to have
some knobs to allow setting it to behave in this way.
That would imply a scheme to define various GRO/SSR semantics, which
then would also be a convenient interface for a driver to report the
semantics of its hardware LRO if it has any.
And it would make crystal clear that the difference between GRO and
LRO is kernel vs hardware, rather than reversible vs not.

-Ed