netdev - Re: [PATCH net-next v2 2/3] net: dsa: add Arrow SpeedChips XRS700x driver

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20201127224646.GA2073444@lunn.ch>
Date:   Fri, 27 Nov 2020 23:46:46 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        George McCollister <george.mccollister@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        "open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next v2 2/3] net: dsa: add Arrow SpeedChips XRS700x
 driver

On Fri, Nov 27, 2020 at 02:14:02PM -0800, Jakub Kicinski wrote:
> On Fri, 27 Nov 2020 22:32:44 +0100 Andrew Lunn wrote:
> > > > So long as these counters are still in ethtool -S, i guess it does not
> > > > matter. That i do trust to be accurate, and probably consistent across
> > > > the counters it returns.  
> > > 
> > > Not in the NIC designs I'm familiar with.  
> > 
> > Many NICs have a way to take a hardware snapshot of all counters.
> > You can then read them out as fast or slow as you want, since you
> > read the snapshot, not the live counters. As a result you can compare
> > counters against each other.
> 
> Curious, does Marvell HW do it?

Yes. Every generation of Marvell SOHO switch has this.

> IDK I find it very questionable if the system design doesn't take into
> account that statistics are retrieved every n seconds. We can perhaps
> scale the default period with the speed of the bus?

You don't actually have much choice. I2C is defined to run at
100Kbps. There is a fast mode which runs at 400Kbps. How do you design
around that? MDIO is around 2.5Mbps, but has 50% overhead from the
preamble. SPI can be up to 50Mbps, but there is no standard set of
speeds. None of the data sheets i've seen ever talk about recommended
scheduling polices for transactions over these busses. But testing has
shown, if you want good PTP, you need to keep them loaded as lightly
as possible. If you don't have PTP it becomes less important.

   Andrew