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: <CAKgT0Uex41aBJX84we2gxNGw6M4s5xGEPnDkGehTZkEE+i+Jhw@mail.gmail.com>
Date:	Wed, 22 Jun 2016 17:11:16 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	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>,
	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 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 ?

Exactly my point.  The problem I have with the bnx2x and qede drivers
is that the NIC driver is using the GRO flag to enable LRO on the
device. It is like arguing that the NIC can do segmentation based on
the GSO flag instead of the TSO flag.  We should be keeping TSO/LRO as
the device features while GSO/GRO are kernel features that don't
directly change any settings on the device.

> Yes, LRO is hard to implement properly compared to TSO,
> but not something that is _fundamentally_ broken.

Yes and no.  More often then not there are issues that pop up as
protocols change.  I'm not assuming they are fundamentally broken.
The bit that I consider broken is that I cannot disable the NIC LRO
functionality without having to disable the stack from doing GRO.  All
I am asking for is LRO controls all of the NIC aggregation features
and GRO be kept a software only feature instead of being tied to a
hardware feature.

> Claiming that hardware assist GRO is not possible is a plain mantra.

I have no issue claiming hardware assist GRO is possible.  My problem
is saying that the GRO feature flag can be used to enable it.  I would
argue that any packet aggregation at the device or driver level is LRO
regardless of how close it comes to GRO feature wise.  GRO should only
be occurring in the receive path after calling the appropriate GRO
function.  Otherwise it becomes really difficult to work around any
possible issues that the hardware assisted GRO introduces without
paying a huge penalty.  We need to keep these feature flags separate.
I thought that was the whole reason why we have the distinction
between LRO and GRO in the first place.

- Alex