[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171219195516.GG6122@localhost.localdomain>
Date: Tue, 19 Dec 2017 17:55:16 -0200
From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To: Michael Chan <michael.chan@...adcom.com>
Cc: David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
Andrew Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW
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
> <marcelo.leitner@...il.com> 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
Powered by blists - more mailing lists