> -----Original Message-----
> From: Intel-wired-lan <[email protected]> On Behalf Of Anton
> Nadezhdin
> Sent: 16 December 2024 20:24
> To: [email protected]
> Cc: [email protected]; Nguyen, Anthony L <[email protected]>;
> Kitszel, Przemyslaw <[email protected]>; [email protected];
> Keller, Jacob E <[email protected]>; Kolacinski, Karol
> <[email protected]>; Olech, Milena <[email protected]>;
> Nadezhdin, Anton <[email protected]>
> Subject: [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: implement low latency
> PHY timer updates
>
> From: Jacob Keller <[email protected]>
>
> 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_L and REG_LL_PROXY_H 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.
>
> Co-developed-by: Karol Kolacinski <[email protected]>
> Signed-off-by: Karol Kolacinski <[email protected]>
> Signed-off-by: Jacob Keller <[email protected]>
> Reviewed-by: Milena Olech <[email protected]>
> Signed-off-by: Anton Nadezhdin <[email protected]>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 105 ++++++++++++++++++++
> drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 4 +
> 2 files changed, 109 insertions(+)
>
Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
