Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>,
	 Maciej Machnikowski <maciej.machnikowski@intel.com>,
	 Jacob Keller <jacob.e.keller@intel.com>,
	 Przemyslaw Korba <przemyslaw.korba@intel.com>,
	 Anthony Nguyen <anthony.l.nguyen@intel.com>,
	 Grzegorz Nitka <grzegorz.nitka@intel.com>,
	 Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Cc: Jacob Keller <jacob.e.keller@intel.com>
Subject: [PATCH iwl-net v3 13/15] ice: skip reading Tx ready bitmap on ports with no timestamps
Date: Fri, 25 Sep 2026 16:56:45 -0700	[thread overview]
Message-ID: <20260925-jk-e825c-timestamp-processing-logic-fixes-srcu-v3-13-6532598e8da8@intel.com> (raw)
In-Reply-To: <20260925-jk-e825c-timestamp-processing-logic-fixes-srcu-v3-0-6532598e8da8@intel.com>

On E82x devices, the interrupt for Tx timestamps are handled by the clock
owner. When an interrupt with the Tx timestamp cause is fired, the clock
owner PF iterates the list of ports and checks for timestamps across all
ports.

The existing logic reads the PHY timestamp ready bitmap before iterating
the list of in-use timestamp indexes, even for ports which have no
timestamps waiting in the software timestamp tracker. This has a
significant and measurable latency impact on reporting Tx timestamps.

Check the bitmap and exit early in the event that there are no timestamps
waiting on a port. Observant reviewers may notice that the check is done
without acquiring the lock. This is fine, as whether the thread sees or
fails to see a new outstanding timestamp does not affect correctness, only
determining whether or not it should do extra work.

Skipping the check has the highest impact on E822 an E825 devices which
iterate all ports in a single thread, but it is applied universally to all
device types since the extra read is unnecessary regardless.

The average latency of a Tx timestamp is impacted by several factors
including system load, the number of timestamp requests, and some random
factors that are difficult to control. However for comparison on my system
with these changes, while operating ptp4l on a single port with a sync rate
of 16/second:

  Before: mean 317.43 microseconds, standard deviation 34.51
  After: mean 189.71 microseconds, standard deviation 43.24

Of course this level of improvement may not be indicative of a production
setup as one might expect timestamps to be operating out of multiple ports
on the device. However, even in that case an improvement is still likely
depending on the actual timestamp rates.

Fixes: d938a8cca88a ("ice: Auxbus devices & driver for E822 TS")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_ptp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
index a5ee8c8edf3d..9dc0b5fa3319 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -576,7 +576,7 @@ static void ice_ptp_process_tx_tstamp(struct ice_ptp_tx *tx)
 	pf = ptp_port_to_pf(ptp_port);
 	hw = &pf->hw;
 
-	if (!tx->init)
+	if (!tx->init || bitmap_empty(tx->in_use, tx->len))
 		return;
 
 	/* Read the Tx ready status first */

-- 
2.56.0.rc0.395.gd1f3524e15dc


  parent reply	other threads:[~2026-09-25 23:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 23:56 [PATCH iwl-net v3 00/15] ice: E82x: timestamp processing logic fixes Jacob Keller
2026-09-25 23:56 ` [PATCH iwl-net v3 01/15] ice: fix removal of PTP timestamp tracker during reset Jacob Keller
2026-10-05 11:02   ` Loktionov, Aleksandr
2026-10-06  1:36   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 02/15] ice: use reference counting and SRCU for PTP port access Jacob Keller
2026-10-06  1:37   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 03/15] ice: fix PHY port restart serialization Jacob Keller
2026-10-06  1:38   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 04/15] ice: set in_use only after preparing Tx timestamp index Jacob Keller
2026-10-06  1:38   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 05/15] ice: call PTP link change only from link events Jacob Keller
2026-09-25 23:56 ` [PATCH iwl-net v3 06/15] ice: E822: keep Tx timestamps disabled during offset calibration Jacob Keller
2026-10-06  1:39   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 07/15] ice: E822: cancel offset verification work during reset preparation Jacob Keller
2026-10-06  1:40   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 08/15] ice: E825: stop clearing PHY_REG_TX_OFFSET_READY Jacob Keller
2026-10-05 11:03   ` Loktionov, Aleksandr
2026-10-06  1:41   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 09/15] ice: E825: clear PHY_REG_TX_MEMORY_STATUS prior to soft reset Jacob Keller
2026-10-05 11:04   ` Loktionov, Aleksandr
2026-10-06  1:41   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 10/15] ice: E825: perform a soft reset when starting the PHY timer Jacob Keller
2026-10-05 11:04   ` Loktionov, Aleksandr
2026-10-06  1:42   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 11/15] ice: wait for in-flight Tx timestamps before flushing the tracker Jacob Keller
2026-10-05 11:05   ` Loktionov, Aleksandr
2026-10-06  1:42   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 12/15] ice: keep Tx timestamp slots tracked until completion or timeout Jacob Keller
2026-10-05 11:01   ` Loktionov, Aleksandr
2026-10-06  1:43   ` Nowlin, Alexander
2026-09-25 23:56 ` Jacob Keller [this message]
2026-10-06  1:44   ` [PATCH iwl-net v3 13/15] ice: skip reading Tx ready bitmap on ports with no timestamps Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 14/15] ice: don't clear in_use until HW clears ready bitmap Jacob Keller
2026-10-06  1:45   ` Nowlin, Alexander
2026-09-25 23:56 ` [PATCH iwl-net v3 15/15] ice: Recalibrate PHY after settime64 on E825-C Jacob Keller
2026-10-06  1:46   ` Nowlin, Alexander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260925-jk-e825c-timestamp-processing-logic-fixes-srcu-v3-13-6532598e8da8@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=grzegorz.nitka@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=maciej.machnikowski@intel.com \
    --cc=przemyslaw.korba@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox