[Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: implement low latency PHY timer updates
Tony Nguyen
anthony.l.nguyen at intel.com
Thu Dec 12 23:42:12 UTC 2024
On 12/10/2024 6:22 AM, Anton Nadezhdin wrote:
> Programming the PHY registers in preparation for an increment value change
> or a timer adjustment on E810 requires issuing Admin Queue commands for
> each PHY register. It has been found that the firmware Admin Queue
> processing occasionally has delays of tens or rarely up to hundreds of
> milliseconds. This delay cascades to failures in the PTP applications which
> depend on these updates being low latency.
>
> Consider a standard PTP profile with a sync rate of 16 times per second.
> This means there is ~62 milliseconds between sync messages. A complete
> cycle of the PTP algorithm
>
> 1) Sync message (with Tx timestamp) from source
> 2) Follow-up message from source
> 3) Delay request (with Tx timestamp) from sink
> 4) Delay response (with Rx timestamp of request) from source
> 5) measure instantaneous clock offset
> 6) request time adjustment via CLOCK_ADJTIME systemcall
>
> The Tx timestamps have a default maximum timeout of 10 milliseconds. If we
> assume that the maximum possible time is used, this leaves us with ~42
> milliseconds of processing time for a complete cycle.
>
> The CLOCK_ADJTIME system call is synchronous and will block until the
> driver completes its timer adjustment or frequency change.
>
> If the writes to prepare the PHY timers get hit by a latency spike of 50
> milliseconds, then the PTP application will be delayed past the point where
> the next cycle should start. Packets from the next cycle may have already
> arrived and are waiting on the socket.
>
> In particular, LinuxPTP ptp4l may start complaining about missing an
> announce message from the source, triggering a fault. In addition, the
> clockcheck logic it uses may trigger. This clockcheck failure occurs
> because the timestamp captured by hardware is compared against a reading of
> CLOCK_MONOTONIC. It is assumed that the time when the Rx timestamp is
> captured and the read from CLOCK_MONOTONIC are relatively close together.
> This is not the case if there is a significant delay to processing the Rx
> packet.
>
> Newer firmware supports programming the PHY registers over a low latency
> interface which bypasses the Admin Queue. Instead, software writes to the
> REG_LL_PROXY_H and REG_LL_PROXY_L registers. Firmware reads these registers and
> then programs the PHY timers.
>
> Implement functions to use this interface when available to program the PHY
> timers instead of using the Admin Queue. This avoids the Admin Queue
> latency and ensures that adjustments happen within acceptable latency
> bounds.
This version doesn't apply. Did you rebase? Also, please include change
logs for new versions.
Thanks,
Tony
> Jacob Keller (5):
> ice: use rd32_poll_timeout_atomic in ice_read_phy_tstamp_ll_e810
> ice: rename TS_LL_READ* macros to REG_LL_PROXY_H_*
> ice: add lock to protect low latency interface
> ice: check low latency PHY timer update firmware capability
> ice: implement low latency PHY timer updates
>
> drivers/net/ethernet/intel/ice/ice_common.c | 3 +
> drivers/net/ethernet/intel/ice/ice_osdep.h | 3 +
> drivers/net/ethernet/intel/ice/ice_ptp.c | 48 ++++--
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 155 +++++++++++++++++---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 17 ++-
> drivers/net/ethernet/intel/ice/ice_type.h | 12 ++
> 6 files changed, 204 insertions(+), 34 deletions(-)
>
>
> base-commit: 4376b34cf49c2f38e761beacd173d1dc15a255fd
More information about the Intel-wired-lan
mailing list