From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: [PATCH net-next 2/4] bnxt_en: Use NETIF_F_GRO_HW.
Date: Tue, 5 Dec 2017 16:10:52 -0200
Message-ID: <20171205181052.GD3327@localhost.localdomain>
References: <1512385967-32339-1-git-send-email-michael.chan@broadcom.com>
 <1512385967-32339-3-git-send-email-michael.chan@broadcom.com>
 <CAJ3xEMghbGNkE5N2+aCMJK_nc2Yivyj2FYnFagTf9nF8xrew6g@mail.gmail.com>
 <CACKFLik-yLSCPMyV__CfDZaZfLWCHo6x74-7bWT+Ox1cVJfMpA@mail.gmail.com>
 <CAJ3xEMg5rS+Q=1hV8aMBQJruOH1A7-dScp_8WZwUQTJ7CKcsTg@mail.gmail.com>
 <1512424845.19682.64.camel@gmail.com>
 <CACKFLi=nDh_xfwwa6jp-amKp21+9SdeUA4TcrVGGvmi8UKGv3A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
        Or Gerlitz <gerlitz.or@gmail.com>,
        David Miller <davem@davemloft.net>,
        Linux Netdev List <netdev@vger.kernel.org>
To: Michael Chan <michael.chan@broadcom.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:34190 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752705AbdLESKz (ORCPT <rfc822;netdev@vger.kernel.org>);
        Tue, 5 Dec 2017 13:10:55 -0500
Content-Disposition: inline
In-Reply-To: <CACKFLi=nDh_xfwwa6jp-amKp21+9SdeUA4TcrVGGvmi8UKGv3A@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, Dec 04, 2017 at 04:07:15PM -0800, Michael Chan wrote:
> As already pointed out, GRO_HW is a subset of GRO.  Packets that
> cannot be aggregated in hardware (due to hardware resource limitations
> or protocol types that it doesn't handle) can just be passed to the
> stack for GRO aggregation.

How would the parameters/limits work in this case? I mean, currently
we have the default weight of 64 packets per napi poll cycle, the
budget of 300 per cycle and also the time constrain,
net.core.netdev_budget_usecs.

With GRO_HW, this 64 limit may be exceeded. I'm looking at qede code
and it works by couting each completion as 1 rcv_pkts
(qede_fp.c:1318). So if it now gets 64 packets, it's up to 64*MTU
aprox, GRO'ed or not. But with GRO_HW, seems it may be much more than
that and which may not be fair with other interfaces in the system.
Drivers supporting GRO_HW probably should account for this.

And how can one control how much time a packet may spend on NIC queue
waiting to be GRO'ed? Does it use the coalescing parameters for that?

  Marcelo