linux-kernel - Re: [PATCH v1 net-next] net: dsa: qca: ar9331: add ethtool stats support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.