[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABJS2x5N6qwe1nO_hWpaTaVjh4sWUDs4UE_g0_scW65_eDqyfA@mail.gmail.com>
Date: Tue, 15 Jul 2025 18:18:06 +0530
From: Naveen Mamindlapalli <naveen130617.lkml@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>
Subject: Re: Clarification: ethtool -S stats persistence across ifconfig down/up
On Mon, Jul 14, 2025 at 6:51 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Mon, Jul 14, 2025 at 12:46:15PM +0530, Naveen Mamindlapalli wrote:
> > Hi All,
> >
> > I am trying to better understand the expected behavior of Netdev
> > statistics reported via `ethtool -S`.
> >
> > Specifically, I would like to clarify:
> > Are drivers expected to retain `ethtool -S` statistics across
> > interface down/up cycles (i.e., ifconfig ethX down followed by
> > ifconfig ethX up)?
> >
> > >From my reading of the kernel documentation:
> > - The file Documentation/networking/statistics.rst states that
> > standard netdev statistics (such as those shown via ip -s link) are
> > expected to persist across interface resets.
> > - However, Documentation/networking/ethtool-netlink.rst (as of Linux
> > v6.15) does not mention any such requirement for `ethtool -S`
> > statistics.
> >
> > So my understanding is that `ethtool -S` statistics may reset across
> > down/up, depending on how the hardware and driver implement the stats.
>
> I'm not sure it is written down anywhere, but the general expectation
> is that they survive a down/up.
>
> Statistic counters going backwards is not so easy to deal with. These
> statistics can be exported to third party systems, e.g. via an SNMP
> agent. So it is better they only go backwards when they wrap around.
>
> Having said that, this topic is not closely looked at when reviewing
> drivers, so i expect there are a number of drivers which do reset to
> zero on close/open.
>
> Feel free to submit a patch extending the documentation, but please
> make it clear that the reality is, some drivers will reset to zero,
> even if the intended behaviour is they don't.
>
> Andrew
Hi Andrew,
Thank you for the clarification. That makes sense, I can see why
counters going backwards would be problematic, and thanks for
clarifying the expected vs actual driver behavior.
I will plan to submit a patch to extend the documentation, explicitly
noting that while the intended behavior is for ethtool -S statistics
to persist across down/up cycles, some drivers may still reset them.
Thanks,
Naveen
Powered by blists - more mailing lists