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  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:   Sun, 18 Oct 2020 00:23:55 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Christian Eggers <ceggers@...i.de>,
        Kurt Kanzenbach <kurt@...utronix.de>
Subject: Re: [RFC PATCH 01/13] net: dsa: add plumbing for custom netdev
 statistics

On Sun, Oct 18, 2020 at 01:15:51AM +0200, Andrew Lunn wrote:
> > +/* Driver statistics, other than those in struct rtnl_link_stats64.
> > + * These are collected per-CPU and aggregated by ethtool.
> > + */
> > +struct dsa_slave_stats {
> > +	__u64			tx_reallocs;
> > +	struct u64_stats_sync	syncp;
> > +} __aligned(1 * sizeof(u64));
> 
> The convention seems to be to use a prefix of pcpu_,
> e.g. pcpu_sw_netstats, pcpu_lstats.

I find the "pcpu_sw_netstats" to be long and useless. I can easily see
it's percpu based on its usage, I don't need to have it in its name.

> Also, why __u64? Neither pcpu_sw_netstats nor pcpu_lstats use __u64.

Ok, I'll confess I stole the beginning from the dpaa2-eth driver prior
to commit d70446ee1f40 ("dpaa2-eth: send a scatter-gather FD instead of
realloc-ing"), since I knew it used to implement this counter. Then I
combined with what was already there for the standard statistics in DSA.

But to be honest, what I dislike a little bit is that we have 2
structures now. For example, netronome nfp has created one struct
nfp_repr_pcpu_stats that holds everything, even if it duplicates some
counters found elsewhere. But I think that's a bit easier to digest from
a maintainability point of view, what do you think?

Powered by blists - more mailing lists