[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201116155605.1309c4eb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 16 Nov 2020 15:56:05 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Russell King <linux@...linux.org.uk>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mips@...r.kernel.org
Subject: Re: [PATCH v1 net-next] net: dsa: qca: ar9331: add ethtool stats
support
On Tue, 17 Nov 2020 01:27:31 +0200 Vladimir Oltean wrote:
> > Note that I said _forwarded_. Frames are either forwarded by the HW or
> > SW (former never hit the CPU, while the latter do hit the CPU or
> > originate from it).
>
> Ah, you were just thinking out loud, I really did not understand what
> you meant by the separation between "forwarded in software" and
> "forwarded in hardware".
> Yes, the hardware typically only gives us MAC-level counters anyway.
> Another way to look at it is that the number of packets forwarded in
> hardware from a given port are equal to the total number of RX packets
> on that MAC minus the packets seen by the CPU coming from that port.
> So all in all, it's the MAC-level counters we should expose in
> .ndo_get_stats64, I'm glad you agree. As for the error packets, I
> suppose that would be a driver-specific aggregate.
Yup, sorry about the confusion, I was only working on those stats
with SDN/OvS/tc hardware, which explains the slight difference in
terminology.
Powered by blists - more mailing lists