On Thu, 14 Oct 2021 12:44:37 +0000 Alvin Šipraga wrote:
> On 10/13/21 5:13 PM, Jakub Kicinski wrote:
> > On Wed, 13 Oct 2021 08:33:36 +0000 Alvin Šipraga wrote:
> >> 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
It can still be used, but standardized interfaces should be preferred
whenever possible, especially when appropriate uAPI already exists.
> - get_eth_{phy,mac,ctrl,rmon}_stats is the new API - add DSA plumbing
> and use this
Yup.
> - get_stats64 orthogonal to ethtool stats but still important - use also
> this
Yes, users should be able to depend on basic interface stats (packets,
bytes, crc errors) to be correct.
> 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.
3 sec seems fine.
