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: <CALx6S36jA7JTwm_gS8n5_xt-7vK4jwarOeoC=30S-zwREoo63Q@mail.gmail.com>
Date:	Wed, 22 Jun 2016 16:59:05 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	Rick Jones <rick.jones2@....com>,
	Yuval Mintz <Yuval.Mintz@...gic.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>
Subject: Re: [PATCH net-next 0/5] qed/qede: Tunnel hardware GRO support

On Wed, Jun 22, 2016 at 4:31 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Wed, 2016-06-22 at 15:56 -0700, Alexander Duyck wrote:
>
>> It could be that you and Rick are running different firmware. I
>> believe you can expose that via "ethtool -i".  This is the ugly bit
>> about all this.  We are offloading GRO into the firmware of these
>> devices with no idea how any of it works and by linking GRO to LRO on
>> the same device you are stuck having to accept either the firmware
>> offload or nothing at all.  That is kind of the point Rick was trying
>> to get at.
>
>
> Well, we offload TSO to the NIC. Or checksums as much as we can.
>
> At one point we have to trust the NIC we plug in our hosts, right ?
>
> Why RX is so different than TX exactly ?
>
LRO requires parsing the packet and hence DPI for things like foo/UDP.
TSO is much more straightforward and does not rely on parsing (e.g.
LRO would require NIC to parse EH, TSO doesn't). Also, TSO is
work-conserving, whereas LRO is not. I don't believe there is any
standard for how NICs are supposed to determined when to set packets
to host. All of this makes LRO much less deterministic and means
there's a lot of variance between NIC implementations. Plus there's
also the question of whether a vendor is testing IPv6. I do think all
this can be "fixed" once we have programmable NICs and we can program
our own implementation of LRO, but until then I think there is
inherent risk in using it. GRO rocks though!

Tom

> Yes, LRO is hard to implement properly compared to TSO,
> but not something that is _fundamentally_ broken.
>
> Claiming that hardware assist GRO is not possible is a plain mantra.
>
>