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

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

Date: Thu, 22 Feb 2024 17:33:45 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: "Nambiar, Amritha" <amritha.nambiar@...el.com>
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 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.