netdev - Re: [RFC net-next 3/3] eth: bnxt: support per-queue statistics

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: <246c7cef-91da-4a75-a29b-c2fca3954dd7@intel.com>
Date: Fri, 23 Feb 2024 12:42:41 -0800
From: "Nambiar, Amritha" <amritha.nambiar@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <davem@...emloft.net>, <netdev@...r.kernel.org>, <edumazet@...gle.com>,
	<pabeni@...hat.com>, <danielj@...dia.com>, <mst@...hat.com>,
	<michael.chan@...adcom.com>
Subject: Re: [RFC net-next 3/3] eth: bnxt: support per-queue statistics

On 2/22/2024 5:33 PM, Jakub Kicinski wrote:
> On Thu, 22 Feb 2024 16:29:15 -0800 Nambiar, Amritha wrote:
>> So, with projection: 0, the counters would remain unchanged after
>> reconfiguration ?
> 
> Yes, device level stats (projection 0) should maintain history across
> reconfig - some form of explicit ethtool --reset $ifc or devlink reload
> may reset them but not changing ring count, attaching XDP or alike.
> 
> Queue level stats (projection 1 or "queue") can be reset when queue is
> recreated, for some drivers doesn't matter but probably better if
> reconfigs reset them.
> 
> I mentioned this in a kdoc comment on struct netdev_stat_ops - the
> justification for different reset regimes is (1) to make driver
> implementations easier but also (2) because the main (only?) known use
> case for queue stats is to check if traffic is balanced. If we run with
> 4 queues and then bump to 8, and stats are not reset, the first 4 queues
> will have much higher counters. So it's hard to tell from a snapshot if
> traffic is balanced or not.

Okay, this makes sense to me and would be highly useful IMO to have the 
queue level stats reset on reconfigs, since ethtool -S doesn't already 
do that.