netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH v1 net-next 1/2] net: mscc: ocelot: remove redundant stats_layout pointers
Date: Mon, 14 Nov 2022 19:43:48 -0800	[thread overview]
Message-ID: <Y3MK9PCz0JQSQNiQ@euler> (raw)
In-Reply-To: <20221114151535.k7rknwmy3erslfwo@skbuf>

Hi Vladimir,

On Mon, Nov 14, 2022 at 03:15:36PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Fri, Nov 11, 2022 at 12:49:23PM -0800, Colin Foster wrote:
> > Ever since commit 4d1d157fb6a4 ("net: mscc: ocelot: share the common stat
> > definitions between all drivers") the stats_layout entry in ocelot and
> > felix drivers have become redundant. Remove the unnecessary code.
> > 
> > Suggested-by: Vladimir Oltean <olteanv@gmail.com>
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> 
> (please also the Microchip development list, people do seem to follow it
> and do respond sometimes)

Apologies there. Honest mistake, as I see get_maintainer was working.

> 
> Before saying anything about this patch set, I wanted to check what's
> the status with my downstream patches for the MAC Merge Layer counters.
> 
> There, vsc9959_stats_layout would get expanded to look like this:
> 
> static const struct ocelot_stat_layout vsc9959_stats_layout[OCELOT_NUM_STATS] = {
> 	OCELOT_COMMON_STATS,
> 	OCELOT_STAT(RX_ASSEMBLY_ERRS),
> 	OCELOT_STAT(RX_SMD_ERRS),
> 	OCELOT_STAT(RX_ASSEMBLY_OK),
> 	OCELOT_STAT(RX_MERGE_FRAGMENTS),
> 	OCELOT_STAT(TX_MERGE_FRAGMENTS),
> 	OCELOT_STAT(RX_PMAC_OCTETS),
> 	OCELOT_STAT(RX_PMAC_UNICAST),
> 	OCELOT_STAT(RX_PMAC_MULTICAST),
> 	OCELOT_STAT(RX_PMAC_BROADCAST),
> 	OCELOT_STAT(RX_PMAC_SHORTS),
> 	OCELOT_STAT(RX_PMAC_FRAGMENTS),
> 	OCELOT_STAT(RX_PMAC_JABBERS),
> 	OCELOT_STAT(RX_PMAC_CRC_ALIGN_ERRS),
> 	OCELOT_STAT(RX_PMAC_SYM_ERRS),
> 	OCELOT_STAT(RX_PMAC_64),
> 	OCELOT_STAT(RX_PMAC_65_127),
> 	OCELOT_STAT(RX_PMAC_128_255),
> 	OCELOT_STAT(RX_PMAC_256_511),
> 	OCELOT_STAT(RX_PMAC_512_1023),
> 	OCELOT_STAT(RX_PMAC_1024_1526),
> 	OCELOT_STAT(RX_PMAC_1527_MAX),
> 	OCELOT_STAT(RX_PMAC_PAUSE),
> 	OCELOT_STAT(RX_PMAC_CONTROL),
> 	OCELOT_STAT(RX_PMAC_LONGS),
> 	OCELOT_STAT(TX_PMAC_OCTETS),
> 	OCELOT_STAT(TX_PMAC_UNICAST),
> 	OCELOT_STAT(TX_PMAC_MULTICAST),
> 	OCELOT_STAT(TX_PMAC_BROADCAST),
> 	OCELOT_STAT(TX_PMAC_PAUSE),
> 	OCELOT_STAT(TX_PMAC_64),
> 	OCELOT_STAT(TX_PMAC_65_127),
> 	OCELOT_STAT(TX_PMAC_128_255),
> 	OCELOT_STAT(TX_PMAC_256_511),
> 	OCELOT_STAT(TX_PMAC_512_1023),
> 	OCELOT_STAT(TX_PMAC_1024_1526),
> 	OCELOT_STAT(TX_PMAC_1527_MAX),
> };
> 
> The issue is that not all Ocelot family switches support the MAC merge
> layer. Namely, only vsc9959 does.
> 
> With your removal of the ability to have a custom per-switch stats layout,
> the only remaining thing for vsc9959 to do is to add a "bool mm_supported"
> to the common struct ocelot, and all the above extra stats will only be read
> from the common code in ocelot_stats.c only if mm_supported is set to true.
> 
> What do you think, is this acceptable?

That's an interesting solution. I don't really have any strong opinions
on this one. I remember we'd had the discussion about making sure the
stats are ordered (so that bulk stat reads don't get fragmented) and that
wasn't an issue here. So I'm happy to go any route, either:

1. I fix up this patch and resubmit
2. I wait until the 9959 code lands, and do some tweaks for mac merge
stats
3. Maybe we deem this patch set unnecessary and drop it, since 9959 will
start using custom stats again.


Or maybe a 4th route, where ocelot->stats_layout remains in tact and
felix->info->stats_layout defaults to the common stats. Only the 9959
would have to override it?


  reply	other threads:[~2022-11-15  3:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 20:49 [PATCH v1 net-next 0/2] cleanup ocelot_stats exposure Colin Foster
2022-11-11 20:49 ` [PATCH v1 net-next 1/2] net: mscc: ocelot: remove redundant stats_layout pointers Colin Foster
2022-11-12  1:08   ` kernel test robot
2022-11-12 18:05   ` Colin Foster
2022-11-14 15:15   ` Vladimir Oltean
2022-11-15  3:43     ` Colin Foster [this message]
2022-11-15 16:08       ` Vladimir Oltean
2022-11-15 17:10         ` Colin Foster
2022-11-15 17:39           ` Vladimir Oltean
2022-11-11 20:49 ` [PATCH v1 net-next 2/2] net: mscc: ocelot: remove unnecessary exposure of stats structures Colin Foster
2022-11-12 10:34   ` kernel test robot
2022-11-14 15:19   ` Vladimir Oltean
2022-11-15  3:47     ` Colin Foster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3MK9PCz0JQSQNiQ@euler \
    --to=colin.foster@in-advantage.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).