Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 14 Nov 2022 19:43:48 -0800
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
Message-ID: <Y3MK9PCz0JQSQNiQ@euler>
References: <20221111204924.1442282-1-colin.foster@in-advantage.com>
 <20221111204924.1442282-2-colin.foster@in-advantage.com>
 <20221114151535.k7rknwmy3erslfwo@skbuf>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221114151535.k7rknwmy3erslfwo@skbuf>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?F9NVCw7sQddeaFiQmugMpoGPIp3KCaKHib/Yc7XOyBdt4X+wuEVU69pQA6kw?=
 =?us-ascii?Q?naf01dTxe1vWzlZMqrVsYPBnyrQi+whxFSzUCZhbIb3xhRJs6TVAdujImjZc?=
 =?us-ascii?Q?XIV3Qahfsj5AZIa9xbiLlO3BV1wRv+WvwZ9cmuw5KJEAj/ZvaXnWiedDrIzC?=
 =?us-ascii?Q?bB/3EjeDICNPIGdehlzF/CoKQYVz1f/cy13UZrpW3812J7kbtQ8tVj0f3YKU?=
 =?us-ascii?Q?ydWuhqRbpwLLGoALfZi7dHjMRqxKrlZR0WyvAT4MpoQnAGw6Nj3uohOG4qtv?=
 =?us-ascii?Q?HGyUJwUzzqIslBKogdae2sha5Cgz7+v3LtkF12N5l7b9CLXlfsmRk2ju1SI8?=
 =?us-ascii?Q?/wUWQf7saUgl3FdQJegIrcLHZiI/GF59Ze4pxv/tRZw+udLe8Gz6j9+fdO4K?=
 =?us-ascii?Q?ZHlumxaMjvkcmwONsKY5zaPvj/yCsaFZnsjipC2GCV7nDq806/k5JWecsoFI?=
 =?us-ascii?Q?VBqzRaYxlt3Sgu9irU42KjGVOebzF69629jaAtB30cLTov0lVSR5S9s0r1rf?=
 =?us-ascii?Q?TNZBTTVnYvx+7PzC6UwL1QupvLR/sO+b/Yw3QWMvKWqpbFkGbf+JpXbT+c8+?=
 =?us-ascii?Q?hd3hX722NvLbbVK7Iv8FbBZOs7jJ6avbSUR3G9mJJ/ny6Ep0OEqpkQfQMJzg?=
 =?us-ascii?Q?cFnieZ8ARAHGHPBRCfXzgkynamEM3GSxf0GJwBkFRIGIw6WYQnGy6dtJ9+dn?=
 =?us-ascii?Q?4iNLNBchlgTxBNgX2mcYWQramhwFcix3yJqQ82O6d3mfmbgzOfinZxfWMfEy?=
 =?us-ascii?Q?EfWwnyYNbLbTkSton+pZG/lRmfgjpE7aYlE/36SoLFDMOWpvnGzEhSOy1QB1?=
 =?us-ascii?Q?d3HwF2I6T+gJoYusvKQalPGkEId3FeJiOSnP1wSsdNXaHRXSZobdtL9xhxLn?=
 =?us-ascii?Q?mySUSsvdcNn0fn1Gyul7TMvIH20huljdDrz8FKKpE5sbI1h7EKJC+3oQiSQh?=
 =?us-ascii?Q?6RYU/2h6mDHvC1VCxR5jgXiFRFz2vjnD57r3zgnQ2tOsiwRi21z+4/Ldx9Rb?=
 =?us-ascii?Q?ifIi5kQTP5Rp8AHelwBkESGO6HyIfh2vC/HGgmyBMchwGJrvFLFcXrNH0Rv7?=
 =?us-ascii?Q?Q/pwqOK8U4aij3Cs6w6ki6m4Up04FoEs0chhUXqJKLY5tYPeo9XupWxH2zUc?=
 =?us-ascii?Q?cLpnNBOZTxZPkMMtOrDq8pM8KxpVS0egwKJTj6SaHxEh1UKPWZrqih24Ndg4?=
 =?us-ascii?Q?4rLrq8adtK+0Q+B/rLvHNSlzGv7zR27uwdcoKzVrXhaI1sHiXD9Sx/ELvT1q?=
 =?us-ascii?Q?Wi6jsGMR3HZpLOy/xfrVCVUiclaJ5T+SJIGq5WwKvMEB1hUWqvzEIiyYCgAw?=
 =?us-ascii?Q?pN63KcrhIGg+muzZ2SIoIwDIf6wMoRcaA3DQBJUHqOxk5qWN5YDZyEdDUUi+?=
 =?us-ascii?Q?Krr05uCktJeA0HwYM4RAOb4ksi4krFYc24/KShi89UJ02cVDSSX93xSuJOaJ?=
 =?us-ascii?Q?Y1JKAMjHk3m0X+7BZzk1679Q2sPV0phin/6ymVMI5SpGX6JBYSOnvfd6q7Bw?=
 =?us-ascii?Q?FJAukqvHmDc92fMQwpAL3w8rKIez2pgyFbbXnMbG6GZELRpIjtxk06HL8VjV?=
 =?us-ascii?Q?EwDEQ/lYjO6xJdYAqLHHdRYptFGAv6m+OzOlJ/OGm09hfTG0nmB+18EcKfam?=
 =?us-ascii?Q?kw=3D=3D?=
X-OriginatorOrg: in-advantage.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e904dab5-7937-47c0-0fe2-08dac6bb9c74
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2351.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2022 03:43:51.5038
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 48e842ca-fbd8-4633-a79d-0c955a7d3aae
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: QO2245com5CfpbJoKQAEKr+4tG2RAxeCuoYtAdUtj2gWY+/R6wyAd620q1AyqAFGuUYsNbkW0/d6xsN1YctYPAgTs7kPUblPU7BOMvQ/ZkM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4411
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?