netdev - Re: [PATCH v2 net-next 6/6] net: dsa: mv88e6xxx: Add "rmon" counter group 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]

Message-ID: <87v89b91n2.fsf@waldekranz.com>
Date: Wed, 06 Dec 2023 09:27:29 +0100
From: Tobias Waldekranz <tobias@...dekranz.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
 f.fainelli@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net-next 6/6] net: dsa: mv88e6xxx: Add "rmon" counter
 group support

On ons, dec 06, 2023 at 02:22, Vladimir Oltean <olteanv@...il.com> wrote:
> On Tue, Dec 05, 2023 at 05:04:18PM +0100, Tobias Waldekranz wrote:
>> +static void mv88e6xxx_get_rmon_stats(struct dsa_switch *ds, int port,
>> +				     struct ethtool_rmon_stats *rmon_stats,
>> +				     const struct ethtool_rmon_hist_range **ranges)
>> +{
>> +	static const struct ethtool_rmon_hist_range rmon_ranges[] = {
>> +		{   64,    64 },
>> +		{   65,   127 },
>> +		{  128,   255 },
>> +		{  256,   511 },
>> +		{  512,  1023 },
>> +		{ 1024, 65535 },
>> +		{}
>> +	};
>> +	struct mv88e6xxx_chip *chip = ds->priv;
>> +	int ret;
>> +
>> +	ret = mv88e6xxx_stats_snapshot(chip, port);
>> +	if (ret < 0)
>> +		return;
>> +
>> +#define MV88E6XXX_RMON_STAT_MAP(_id, _member)				\
>> +	mv88e6xxx_stats_get_stat(chip, port,				\
>> +				 &mv88e6xxx_hw_stats[MV88E6XXX_HW_STAT_ID_ ## _id], \
>> +				 &rmon_stats->stats._member)
>> +
>> +	MV88E6XXX_RMON_STAT_MAP(in_undersize, undersize_pkts);
>> +	MV88E6XXX_RMON_STAT_MAP(in_oversize, oversize_pkts);
>> +	MV88E6XXX_RMON_STAT_MAP(in_fragments, fragments);
>> +	MV88E6XXX_RMON_STAT_MAP(in_jabber, jabbers);
>> +	MV88E6XXX_RMON_STAT_MAP(hist_64bytes, hist[0]);
>> +	MV88E6XXX_RMON_STAT_MAP(hist_65_127bytes, hist[1]);
>> +	MV88E6XXX_RMON_STAT_MAP(hist_128_255bytes, hist[2]);
>> +	MV88E6XXX_RMON_STAT_MAP(hist_256_511bytes, hist[3]);
>> +	MV88E6XXX_RMON_STAT_MAP(hist_512_1023bytes, hist[4]);
>> +	MV88E6XXX_RMON_STAT_MAP(hist_1024_max_bytes, hist[5]);
>> +
>> +#undef MV88E6XXX_RMON_STAT_MAP
>> +
>> +	*ranges = rmon_ranges;
>> +}
>
> I just noticed that this doesn't populate the TX counters, just RX.
>
> I haven't tried it, but I think the Histogram Mode bits (11:10) of the
> Stats Operation Register might be able to control what gets reported for
> the Set 4 of counters. Currently AFAICS, the driver always sets it to
> MV88E6XXX_G1_STATS_OP_HIST_RX_TX, aka what gets reported to
> "rx-rmon-etherStatsPkts64to64Octets" is actually an RX+TX counter.

You have a keen eye! Yes, that is what's happening.

> What's the story behind this?

I think the story starts, and ends, with this value being the hardware
default.

Seeing as the hardware only has a single set of histogram counters, it
seems to me like we have to prioritize between:

1. Keeping Rx+Tx: Backwards-compatible, but we can't export any histogram via
   the standard RMON group.

2. Move to Rx-only: We can export them via the RMON group, but we change
   the behavior of the "native" counters.

3. Move to Tx-only: We can export them via the RMON group, but we change
   the behavior of the "native" counters.

Looking at RFC2819, which lays out the original RMON MIB, we find this
description:

    etherStatsPkts64Octets OBJECT-TYPE
        SYNTAX     Counter32
        UNITS      "Packets"
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
            "The total number of packets (including bad
            packets) received that were 64 octets in length
            (excluding framing bits but including FCS octets)."
        ::= { etherStatsEntry 14 }

In my opinion, this gives (2) a clear edge over (3), so we're down to
choosing between (1) and (2). Personally, I lean towards (2), as I think
it is more useful because:

- Most people will tend to assume that the histogram counters refers to
  those defined in RFC2819 anyway

- It means we can deliver _something_ rather than nothing to someone
  building an operating system, who is looking for a hardware
  independent way of providing diagnostics