From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Chan Subject: Re: [PATCH net-next 1/4] net: Introduce NETIF_F_GRO_HW Date: Mon, 4 Dec 2017 10:23:03 -0800 Message-ID: References: <1512385967-32339-1-git-send-email-michael.chan@broadcom.com> <1512385967-32339-2-git-send-email-michael.chan@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: David Miller , Netdev , Ariel Elior , everest-linux-l2@cavium.com To: Alexander Duyck Return-path: Received: from mail-oi0-f65.google.com ([209.85.218.65]:43607 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077AbdLDSXG (ORCPT ); Mon, 4 Dec 2017 13:23:06 -0500 Received: by mail-oi0-f65.google.com with SMTP id f69so12357125oig.10 for ; Mon, 04 Dec 2017 10:23:06 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Mon, Dec 4, 2017 at 8:47 AM, Alexander Duyck wrote: > On Mon, Dec 4, 2017 at 3:12 AM, Michael Chan 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 >> Cc: everest-linux-l2@cavium.com >> Signed-off-by: Michael Chan > > 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.