From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW Date: Tue, 19 Dec 2017 17:55:16 -0200 Message-ID: <20171219195516.GG6122@localhost.localdomain> References: <1513411784-17653-1-git-send-email-michael.chan@broadcom.com> <20171219.105024.1047087594002892419.davem@davemloft.net> <20171219190426.GF6122@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Miller , Netdev , Andrew Gospodarek To: Michael Chan Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38108 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752338AbdLSTzS (ORCPT ); Tue, 19 Dec 2017 14:55:18 -0500 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Dec 19, 2017 at 11:25:29AM -0800, Michael Chan wrote: > On Tue, Dec 19, 2017 at 11:04 AM, Marcelo Ricardo Leitner > wrote: > > Can we clarify on the meaning/expectations of dev_weight? The > > documentation currently says: > > The maximum number of packets that kernel can handle on a NAPI > > interrupt, it's a Per-CPU variable. > > > > I believe 'packets' here refers to packets on the wire. > > > > For drivers doing LRO, we don't have visibility on how many > > packets were aggregated so they count as 1, aggregated or not. > > > > But for GRO_HW, drivers implementing it will get a bonus on its > > dev_weight because instead of pulling 5 packets in a cycle to create 1 > > gro'ed skb, it will pull 1 big packet (which includes 5) and count it > > as 1. > > > > Right, as I replied to you earlier, it's very simple to make this > adjustment for GRO_HW packets in the driver. I will make this change > for bnxt_en in my next net-next patchset and I will update the > dev_weight documentation as well. > Sounds like just the documentation would be enough. I agree with Dave in the other reply. It makes sense to count it as 1, but getting that more clear in the doc is welcomed. Thanks, Marcelo