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: <CALx6S341Pb-fq+trudZDOY3SpFzJvyqhrTGQd+7t0hDc3Jr_ig@mail.gmail.com>
Date:	Fri, 24 Jun 2016 09:31:12 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Edward Cree <ecree@...arflare.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	Yuval Mintz <Yuval.Mintz@...gic.com>,
	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>,
	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 Fri, Jun 24, 2016 at 6:09 AM, Edward Cree <ecree@...arflare.com> wrote:
> 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,

Because you took this OT... ;-)

LRO/GRO is the one of the five common offloads that has no generic
analogue and requires protocol specific logic. For instance each
IP-over-foo encapsulation needs kernel code for GRO, device/driver
code for LRO. I think the answer here is to make both GRO and LRO to
be user programmable via BPF. That is, instead of needing to add code
or buy a new device to support every new protocol, we really just want
to write a program for it that runs in any environment. In the case of
LRO this becomes especially important since it resolves the "black
box" nature of LRO in devices, so design goals like ensuring LRO is
"close enough to GRO" become something we (the stack) have some
control over.

We've already moved GRO for to be a attribute of a UDP sockets, it is
not much of a stretch now to allow applications to define their own
GRO for their protocols (I'm thinking protocols like QUIC or TOU could
use this).

For programmable LRO I think the solution is to use XDP. For instance
protocol specific parsing would done by the BPF program to identify
the flows, and the infrastructure would provide the backend handling.
The advantage of XDP for this is that it is not platform specific, so
programmable LRO could be implemented in the driver (probably
leveraging existing LRO solution like sfc), or it could be implemented
implemented in HW using the exact same program (with HW support for
BPF/XDP). Since such a program allows arbitrary parsing and flow
lookup, we can match on specific n-tuples as needed to resolve the
UDP-encapsulation identification problem.

Tom

> -Ed