On Mon, Dec 4, 2017 at 8:47 AM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On Mon, Dec 4, 2017 at 3:12 AM, Michael Chan <michael.c...@broadcom.com> > wrote: >> 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 <ariel.el...@cavium.com> >> Cc: everest-linux...@cavium.com >> Signed-off-by: Michael Chan <michael.c...@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.
