Re: [RFC PATCH 01/13] net: dsa: add plumbing for custom netdev statistics

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Sun, Oct 18, 2020 at 03:09:32PM +0200, Heiner Kallweit wrote:
> On 18.10.2020 14:16, Vladimir Oltean wrote:
> > On Sun, Oct 18, 2020 at 02:02:46PM +0200, Heiner Kallweit wrote:
> >> Wouldn't a simple unsigned long (like in struct net_device_stats) be
> >> sufficient here? This would make handling the counter much simpler.
> >> And as far as I understand we talk about a packet counter that is
> >> touched in certain scenarios only.
> > 
> > I don't understand, in what sense 'sufficient'? This counter is exported
> > to ethtool which works with u64 values, how would an unsigned long,
> > which is u32 on 32-bit systems, help?
> > 
> Sufficient for me means that it's unlikely that a 32 bit counter will
> overflow. Many drivers use the 32 bit counters (on a 32bit system) in
> net_device_stats for infrequent events like rx/tx errors, and 64bit
> counters only for things like rx/tx bytes, which are more likely to
> overflow.

2^32 = 4,294,967,296 = 4 billion packets
Considering that every packet that needs TX timestamping must be
reallocated, protocols such as IEEE 802.1AS will trigger 5 reallocs per
second. So time synchronization alone (background traffic, by all
accounts) will make this counter overflow in 27 years.
Every packet flooded or multicast by the bridge will also trigger
reallocs. In this case it is not difficult to imagine that overflows
might occur sooner.

Even if the above wasn't true. What becomes easier when I make the
counter an unsigned long? I need to make arch-dependent casts between an
unsigned long an an u64 when I expose the counter to ethtool, and there
it ends up being u64 too, doesn't it?