Hi Jakub,
On Fri, Nov 27, 2020 at 10:36:42PM +0100, Andrew Lunn wrote:
> > Either way, can we conclude that ndo_get_stats64 is not a replacement
> > for ethtool -S, since the latter is blocking and, if implemented correctly,
> > can return the counters at the time of the call (therefore making sure
> > that anything that happened before the syscall has been accounted into
> > the retrieved values), and the former isn't?
>
> ethtool -S is the best source of consistent, up to date statistics we
> have. It seems silly not to include everything the hardware offers
> there.
To add to this, it would seem odd to me if we took the decision to not
expose MAC-level counters any longer in ethtool. Say the MAC has a counter
named rx_dropped. If we are only exposing this counter in ndo_get_stats64,
then we could hit the scenario where this counter keeps incrementing,
but it is the network stack who increments it, and not the MAC.
dev_get_stats() currently does:
storage->rx_dropped += (unsigned
long)atomic_long_read(&dev->rx_dropped);
storage->tx_dropped += (unsigned
long)atomic_long_read(&dev->tx_dropped);
storage->rx_nohandler += (unsigned
long)atomic_long_read(&dev->rx_nohandler);
thereby clobbering the MAC-provided counter. We would not know if it is
a MAC-level drop or not.
