On Mon, Dec 4, 2017 at 8:47 AM, Alexander Duyck
[off-list ref] wrote:

On Mon, Dec 4, 2017 at 3:12 AM, Michael Chan [off-list ref] wrote:

quoted

Introduce NETIF_F_GRO_HW feature flag for NICs that support hardware
GRO.  With this flag, we can now independently turn on or off hardware
GRO when GRO is on.  Hardware GRO guarantees that packets can be
re-segmented by TSO/GSO to reconstruct the original packet stream.

Cc: Ariel Elior <redacted>
Cc: everest-linux-l2@cavium.com
Signed-off-by: Michael Chan <michael.chan@broadcom.com>

Do we really need yet another feature bit for this? We already have
LRO and GRO and now we have to add something that isn't quite either
one?

I think so, to be consistent with TSO/GSO on the transmit side.  On
the receive side, we have LRO/GRO_HW/GRO.  There is difference between
LRO/GRO_HW that we need to distinguish between the 2.

I think I would rather have something like a netdev private flag that
says LRO assembled frames are routable and just have this all run over
the LRO flag with a test for the private flag to avoid triggering the
LRO disable in the case of the flag being present. Really this is just
a clean LRO implementation anyway so maybe we should just go that
route where LRO is the hardware offload and GRO is the generic
software implementation of that offload. That way when GRO gets some
new feature that your hardware doesn't support we don't have to argue
about the differences since LRO is meant to be a limited
implementation anyway due to the nature of it being in hardware.

Private flag will work.  But a standard feature flag is better since
there are multiple drivers supporting this.  A standard way to turn
this on/off is a better user experience.  It's also consistent with
TSO/GSO on the transmit side.

To me it just seems like this is an attempt to use the GRO name as a
marketing term and I really don't like the feel of it.

I disagree with this.  It's more than a marketing term.