Re: [Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: implement low latency PHY timer updates

[Tony Nguyen <anthony.l.nguyen@intel.com>]

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