netdev - Re: [PATCH RFC v2 1/6] ethtool: add interface to read Tx hardware timestamping 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]

Message-ID: <20240313174107.68ca4ff1@kernel.org>
Date: Wed, 13 Mar 2024 17:41:07 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Rahul Rameshbabu <rrameshbabu@...dia.com>
Cc: ahmed.zaki@...el.com, aleksander.lobakin@...el.com,
 alexandre.torgue@...s.st.com, andrew@...n.ch, corbet@....net,
 davem@...emloft.net, dtatulea@...dia.com, edumazet@...gle.com,
 gal@...dia.com, hkallweit1@...il.com, jacob.e.keller@...el.com,
 jiri@...nulli.us, joabreu@...opsys.com, justinstitt@...gle.com,
 kory.maincent@...tlin.com, leon@...nel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, liuhangbin@...il.com,
 maxime.chevallier@...tlin.com, netdev@...r.kernel.org, pabeni@...hat.com,
 paul.greenwalt@...el.com, przemyslaw.kitszel@...el.com,
 rdunlap@...radead.org, richardcochran@...il.com, saeed@...nel.org,
 tariqt@...dia.com, vadim.fedorenko@...ux.dev, vladimir.oltean@....com,
 wojciech.drewek@...el.com
Subject: Re: [PATCH RFC v2 1/6] ethtool: add interface to read Tx hardware
 timestamping statistics

On Wed, 13 Mar 2024 17:26:11 -0700 Rahul Rameshbabu wrote:
> Makes sense given that these are stale and should have been changed
> between my v1 and v2. Here is my new attempt at this.
> 
>  /**
>   * struct ethtool_ts_stats - HW timestamping statistics
>   * @tx_stats: struct group for TX HW timestamping
>   *	@pkts: Number of packets successfully timestamped by the hardware.
>   *	@lost: Number of hardware timestamping requests where the timestamping
>   *            information from the hardware never arrived for submission with
>   *            the skb.

Should we give some guidance to drivers which "ignore" time stamping
requests if they used up all the "slots"? Even if just temporary until
they are fixed? Maybe we can add after all the fields something like:

  For drivers which ignore further timestamping requests when there are
  too many in flight, the ignored requests are currently not counted by
  any of the statistics.

Adjust as needed, I basing this on the vague memory that this was 
the conclusion in the last discussion :)

>   *	@err: Number of arbitrary timestamp generation error events that the
>   *           hardware encountered.
>   */

Just to be crystal clear let's also call out that @lost is not included
in @err.