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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201116230053.ddub7p6lvvszz7ic@skbuf>
Date:   Tue, 17 Nov 2020 01:00:53 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 Mon, Nov 16, 2020 at 02:35:44PM -0800, Jakub Kicinski wrote:
> On Tue, 17 Nov 2020 00:21:46 +0200 Vladimir Oltean wrote:
> > On Mon, Nov 16, 2020 at 01:34:53PM -0800, Jakub Kicinski wrote:
> > > You must expose relevant statistics via the normal get_stats64 NDO
> > > before you start dumping free form stuff in ethtool -S.
> >
> > Completely agree on the point, Jakub, but to be honest we don't give him
> > that possibility within the DSA framework today, see .ndo_get_stats64 in
> > net/dsa/slave.c which returns the generic dev_get_tstats64 implementation,
> > and not something that hooks into the hardware counters, or into the
> > driver at all, for that matter.
>
> Simple matter of coding, right? I don't see a problem.
>
> Also I only mentioned .ndo_get_stats64, but now we also have stats in
> ethtool->get_pause_stats.

Yes, sure we can do that. The pause stats and packet counter ops would
need to be exposed to the drivers by DSA first, though. Not sure if this
is something you expect Oleksij to do or if we could pick that up separately
afterwards.

> > But it's good that you raise the point, I was thinking too that we
> > should do better in terms of keeping the software counters in sync with
> > the hardware. But what would be a good reference for keeping statistics
> > on an offloaded interface? Is it ok to just populate the netdev counters
> > based on the hardware statistics?
>
> IIRC the stats on the interface should be a sum of forwarded in software
> and in hardware. Which in practice means interface HW stats are okay,
> given eventually both forwarding types end up in the HW interface
> (/MAC block).

A sum? Wouldn't that count the packets sent/received by the stack twice?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ