[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrqsTY0uUy4AwKHN@lunn.ch>
Date: Tue, 28 Jun 2022 09:22:53 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Vladimir Oltean <olteanv@...il.com>,
Oleksij Rempel <o.rempel@...gutronix.de>,
Woojung Huh <woojung.huh@...rochip.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Lukas Wunner <lukas@...ner.de>, UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next v1 2/3] net: dsa: ar9331: add support for pause
stats
> Yeah, the corrections are always iffy. I understand the doubts, and we
> can probably leave things "under-specified" until someone with a strong
> preference comes along. But I hope that the virt example makes it clear
> that neither of the choices is better (SR-IOV NICs would have to start
> adding the pause if we declare rtnl stats as inclusive).
>
> I can see advantages to both counting (they are packets) and not
> counting those frames (Linux doesn't see them, they get "invented"
> by HW).
>
> Stats are hard.
I doubt we can define it either way. I once submitted a patch for one
driver to make it ignore CRC bytes. It then gave the exact same counts
as another hardware i was using, making the testing i was doing
simpler.
The patch got rejected simply because we have both, with CRC and
without CRC, neither is correct, neither is wrong.
So i would keep it KISS, pause frames can be included, but i would not
go to extra effort to include them, or to exclude them.
Andrew
Powered by blists - more mailing lists