netdev - Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO

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]

Date:   Fri, 29 Dec 2017 21:20:02 -0800
From:   Michael Chan <michael.chan@...adcom.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     Sabrina Dubroca <sd@...asysnail.net>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Andrew Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW

On Fri, Dec 29, 2017 at 7:12 AM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Fri, Dec 29, 2017 at 4:43 AM, Sabrina Dubroca <sd@...asysnail.net> wrote:
>> 2017-12-22, 10:14:32 -0800, Alexander Duyck wrote:
>>> On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca <sd@...asysnail.net> wrote:
>>> > IIUC, with the patches that were applied, each driver can define
>>> > whether GRO_HW depends on GRO? From a user's perspective, this
>>> > inconsistent behavior is going to be quite confusing.
>>> >
>>> > Worse than inconsistent behavior, it looks like a driver deciding that
>>> > GRO_HW doesn't depend on GRO is going to introduce a change of
>>> > behavior.  Previously, when GRO was disabled, there wouldn't be any
>>> > packet over MTU handed to the network stack.  Now, even if GRO is
>>> > disabled, GRO_HW might still be enabled, so we might get over-MTU
>>> > packets because of hardware GRO.
>>>
>>> This isn't actually true. LRO was still handling packets larger than
>>> MTU over even when GRO was disabled.
>>
>> Sure, LRO will also cause that, but we're speaking in the context of
>> GRO here, which means no LRO.
>
> We are talking about GRO_HW. Which is basically aggregation being
> performed in hardware. The choice of name is unfortunate though since
> it implies this is GRO when what is actually happening is just
> GRO-like. Really the only difference between LRO and GRO_HW is that
> the frames are better formed in the final result. It is a matter of
> what is performed versus where it is performed.

I think the name GRO_HW is perfectly fine.  It is GRO aggregation done
in hardware, and hardware providing extra information to the driver to
setup the SKB just like GRO.  I don't know what better name to call it
than GRO_HW.