[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80c80992-85c2-d971-ce1c-a37f8199da7a@bang-olufsen.dk>
Date: Thu, 14 Oct 2021 12:44:37 +0000
From: Alvin Šipraga <ALSI@...g-olufsen.dk>
To: Jakub Kicinski <kuba@...nel.org>
CC: Alvin Šipraga <alvin@...s.dk>,
Linus Walleij <linus.walleij@...aro.org>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Rob Herring <robh+dt@...nel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Michael Rasmussen <MIR@...g-olufsen.dk>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 5/6] net: dsa: realtek-smi: add rtl8365mb
subdriver for RTL8365MB-VC
On 10/13/21 5:13 PM, Jakub Kicinski wrote:
> On Wed, 13 Oct 2021 08:33:36 +0000 Alvin Šipraga wrote:
>> On 10/12/21 5:27 PM, Jakub Kicinski wrote:
>>> On Tue, 12 Oct 2021 14:35:54 +0200 Alvin Šipraga wrote:
>>>> + { 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
>
>> 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.
>
>>> 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);
Powered by blists - more mailing lists