netdev - Re: [PATCH net-next v5] ethtool: linkstate: add a statistic for PHY down events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y2VzoD5uwW64yYgD@shell.armlinux.org.uk>
Date:   Fri, 4 Nov 2022 20:18:40 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        pabeni@...hat.com, Florian Fainelli <f.fainelli@...il.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Andrew Lunn <andrew@...n.ch>, corbet@....net,
        hkallweit1@...il.com, huangguangbin2@...wei.com,
        chenhao288@...ilicon.com, moshet@...dia.com,
        linux@...pel-privat.de, linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next v5] ethtool: linkstate: add a statistic for PHY
 down events

On Fri, Nov 04, 2022 at 12:01:25PM -0700, Jakub Kicinski wrote:
> The previous attempt to augment carrier_down (see Link)
> was not met with much enthusiasm so let's do the simple
> thing of exposing what some devices already maintain.
> Add a common ethtool statistic for link going down.
> Currently users have to maintain per-driver mapping
> to extract the right stat from the vendor-specific ethtool -S
> stats. carrier_down does not fit the bill because it counts
> a lot of software related false positives.
> 
> Add the statistic to the extended link state API to steer
> vendors towards implementing all of it.
> 
> Implement for bnxt and all Linux-controlled PHYs. mlx5 and (possibly)
> enic also have a counter for this but I leave the implementation
> to their maintainers.

Hi Jakub,

I guess we'll need phylink to support this as well, so phylink using
drivers can provide this statistic not only for phylib based PHYs, but
also for direct SFP connections as well.

Thinking about the complexities of copper SFPs that may contain a PHY,
it seems to me that the sensible implementation would be for phylink
to keep the counter and not use the phylib counter (as that PHY may
be re-plugged and thus the count can reset back to zero) which I
suspect userspace would not be prepared for.

Russell.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!