linux-kernel - Re: [PATCH net-next V2 2/3] net/mlx5e: Add device PCIe congestion ethtool stats

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]

Message-ID: <nqfa765k7djsxh7w5hecuzt6r4hakbyocrp5wtqv63jyrjv3z2@qdar7f2osjcj>
Date: Sat, 12 Jul 2025 07:55:27 +0000
From: Dragos Tatulea <dtatulea@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>, Tariq Toukan <tariqt@...dia.com>
Cc: Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Saeed Mahameed <saeed@...nel.org>, Gal Pressman <gal@...dia.com>, Leon Romanovsky <leon@...nel.org>, 
	Saeed Mahameed <saeedm@...dia.com>, Mark Bloch <mbloch@...dia.com>, Jonathan Corbet <corbet@....net>, 
	netdev@...r.kernel.org, linux-rdma@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next V2 2/3] net/mlx5e: Add device PCIe congestion
 ethtool stats

On Fri, Jul 11, 2025 at 04:25:04PM -0700, Jakub Kicinski wrote:
> On Thu, 10 Jul 2025 09:51:31 +0300 Tariq Toukan wrote:
> > +   * - `pci_bw_inbound_high`
> > +     - The number of times the device crossed the high inbound pcie bandwidth
> > +       threshold. To be compared to pci_bw_inbound_low to check if the device
> > +       is in a congested state.
> > +       If pci_bw_inbound_high == pci_bw_inbound_low then the device is not congested.
> > +       If pci_bw_inbound_high > pci_bw_inbound_low then the device is congested.
> > +     - Tnformative
> 
> The metrics make sense, but utilization has to be averaged over some
> period of time to be meaningful. Can you shad any light on what the
> measurement period or algorithm is?
>
The measurement period in FW is 200 ms.

> > +	changes = cong_event->state ^ new_cong_state;
> > +	if (!changes)
> > +		return;
> 
> no risk of the high / low events coming so quickly we'll miss both?
Yes it is possible and it is fine because short bursts are not counted. The
counters are for sustained high PCI BW usage.

> Should there be a counter for "mis-firing" of that sort?
> You'd be surprised how long the scheduling latency for a kernel worker
> can be on a busy server :(
>
The event is just a notification to read the state from FW. If the
read is issued later and the state has not changed then it will not be
considered.

Thanks,
Dragos