On 10/13/21 5:13 PM, Jakub Kicinski wrote:

On Wed, 13 Oct 2021 08:33:36 +0000 Alvin Šipraga wrote:

quoted

On 10/12/21 5:27 PM, Jakub Kicinski wrote:

quoted

On Tue, 12 Oct 2021 14:35:54 +0200 Alvin Šipraga wrote:

quoted

+	{ 0, 4, 2, "dot3StatsFCSErrors" },
+	{ 0, 6, 2, "dot3StatsSymbolErrors" },
+	{ 0, 8, 2, "dot3InPauseFrames" },
+	{ 0, 10, 2, "dot3ControlInUnknownOpcodes" },

...

You must expose counters via existing standard APIs.

You should implement these ethtool ops:

I implement the dsa_switch_ops callback .get_ethtool_stats, using an
existing function rtl8366_get_ethtool_stats in the switch helper library
rtl8366.c. It was my understanding that this is the correct way to
expose counters within the DSA framework - please correct me if that is
wrong.

It's the legacy way, today we have a unified API for reporting those
stats so user space SW doesn't have to maintain a myriad string matches
to get to basic IEEE stats across vendors. Driver authors have a truly
incredible ability to invent their own names for standard stats. It
appears that your pick of names is also unique :)

It should be trivial to plumb the relevant ethtool_ops thru to
dsa_switch_ops if relevant dsa ops don't exist.

You should also populate correct stats in dsa_switch_ops::get_stats64
(see the large comment above the definition of struct
rtnl_link_stats64 for mapping). A word of warning there, tho, that
callback runs in an atomic context so if your driver needs to block it
has to read the stats periodically from a async work.

OK, so just to clarify:

- get_ethtool_stats is deprecated - do not use
- get_eth_{phy,mac,ctrl,rmon}_stats is the new API - add DSA plumbing 
and use this
- get_stats64 orthogonal to ethtool stats but still important - use also 
this

For stats64 I will need to poll asynchronously - do you have any 
suggestion for how frequently I should do that? I see one DSA driver 
doing it every 3 seconds, for example.

Thanks

	Alvin

quoted

The structure you highlight is just some internal glue to sort out the
internal register mapping. I borrowed the approach from the existing
rtl8366rb.c Realtek SMI subdriver.

The callbacks listed below are relatively new, they may have not
existed when that driver was written. Also I may have missed it
in review.

quoted

quoted

	void	(*get_eth_phy_stats)(struct net_device *dev,
				     struct ethtool_eth_phy_stats *phy_stats);
	void	(*get_eth_mac_stats)(struct net_device *dev,
				     struct ethtool_eth_mac_stats *mac_stats);
	void	(*get_eth_ctrl_stats)(struct net_device *dev,
				      struct ethtool_eth_ctrl_stats *ctrl_stats);
	void	(*get_rmon_stats)(struct net_device *dev,
				  struct ethtool_rmon_stats *rmon_stats,
				  const struct ethtool_rmon_hist_range **ranges);