Message-ID: <18a7b477-9b4b-42ad-8738-05c3c4b497b5@intel.com>
Date: Thu, 29 Jan 2026 16:33:49 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<przemyslaw.korba@...el.com>, Aleksandr Loktionov
	<aleksandr.loktionov@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] i40e: only timestamp PTP event
 packets



On 1/29/2026 3:45 PM, Paul Menzel wrote:
> Dear Jacob,
> 
> 
> Thank you for the patch.
> 
> Am 29.01.26 um 22:52 schrieb Jacob Keller:
>> The i40e_ptp_set_timestamp_mode() function is responsible for configuring
>> hardware timestamping. When programming receive timestamping, the logic
>> must determine how to configure the PRTTSYN_CTL1 register for receive
>> timestamping.
>>
>> The i40e hardware does not support timestamping all frames. Instead,
>> timestamps are captured into one of the four PRTTSYN_RXTIME registers.
>>
>> Currently, the driver configures hardware to timestamp all V2 packets on
>> ports 319 and 320, including all message types. This timestamps
>> significantly more packets than is actually requested by the
>> HWTSTAMP_FILTER_PTP_V2_EVENT filter type.
>>
>> The documentation for HWTSTAMP_FILTER_PTP_V2_EVENT indicates that it 
>> should
>> timestamp PTP v2 messages on any layer, including any kind of event
>> packets.
>>
>> Timestamping other packets is acceptable, but not required by the filter.
>> Doing so wastes valuable slots in the Rx timestamp registers. For most
>> applications this doesn't cause a problem. However, for extremely high
>> rates of messages, it becomes possible that one of the critical event
>> packets is not timestamped.
>>
>> The PTP protocol only requires timestamps for event messages on port 319,
>> but hardware is timestamping on both 319 and 320, and timestamping 
>> message
>> types which do not need a timestamp value.
>>
>> The i40e hardware actually has a more strict filtering option. First, 
>> only
>> timestamp layer 4 messages on port 319 instead of both 319 and 320. 
>> Second,
>> note that hardware has a specific mode to timestamp only event packets
>> (those with message type < 8).
>>
>> Update the configuration to use this mode, so that timestamps are 
>> captured
>> for only event messages. This replaces the use of the 'wildcard' 
>> option of
>> the V2MESSTYPE field which caused timestamping of all message types
>> regardless of whether it was an event message.
>>
>> This avoids wasting the valuable Rx timestamp register slots on non-event
>> frames, and may reduce faults when operating under high event rates.
> 
> Do you have a test case to reproduce this?
> 

If a remote PTP client has a high sync rate (for example ptp4l with 
--logSyncInterval -4 or -5) it can potentially fail to get receive 
timestamps due to missing slots. This may happen because we're wasting 
some slots timestamping follow up messages even though these are not 
Event frames according to the standard. I originally developed this 
patch while trying to solve a particular missed timestamp bug but we 
ultimately root caused that issue to a different problem, and this 
change was only an insufficient stop gap, as we still had the other 
issue. See:

https://lore.kernel.org/intel-wired-lan/20251120120750.400715-2-przemyslaw.korba@intel.com/

This change would potentially allow an even higher message rate without 
issues, but we tested the specific deployment that was using -4 for 16 
sync per second and it was not necessary.

> Can the other mode be enabled somehow for people needing port 320 and 
> timestamps on every message?
> 
No. The existing uAPI does not have a way of expressing that, and 
applications should not rely on device-specific quirks like this.

Here's the complete list of existing filters:

> /* possible values for hwtstamp_config->rx_filter */
> enum hwtstamp_rx_filters {
>         /* time stamp no incoming packet at all */
>         HWTSTAMP_FILTER_NONE,
> 
>         /* time stamp any incoming packet */
>         HWTSTAMP_FILTER_ALL,
> 
>         /* return value: time stamp all packets requested plus some others */
>         HWTSTAMP_FILTER_SOME,
> 
>         /* PTP v1, UDP, any kind of event packet */
>         HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
>         /* PTP v1, UDP, Sync packet */
>         HWTSTAMP_FILTER_PTP_V1_L4_SYNC,
>         /* PTP v1, UDP, Delay_req packet */
>         HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ,
>         /* PTP v2, UDP, any kind of event packet */
>         HWTSTAMP_FILTER_PTP_V2_L4_EVENT,
>         /* PTP v2, UDP, Sync packet */
>         HWTSTAMP_FILTER_PTP_V2_L4_SYNC,
>         /* PTP v2, UDP, Delay_req packet */
>         HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ,
> 
>         /* 802.AS1, Ethernet, any kind of event packet */
>         HWTSTAMP_FILTER_PTP_V2_L2_EVENT,
>         /* 802.AS1, Ethernet, Sync packet */
>         HWTSTAMP_FILTER_PTP_V2_L2_SYNC,
>         /* 802.AS1, Ethernet, Delay_req packet */
>         HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ,
> 
>         /* PTP v2/802.AS1, any layer, any kind of event packet */
>         HWTSTAMP_FILTER_PTP_V2_EVENT,
>         /* PTP v2/802.AS1, any layer, Sync packet */
>         HWTSTAMP_FILTER_PTP_V2_SYNC,
>         /* PTP v2/802.AS1, any layer, Delay_req packet */
>         HWTSTAMP_FILTER_PTP_V2_DELAY_REQ,
> 
>         /* NTP, UDP, all versions and packet modes */
>         HWTSTAMP_FILTER_NTP_ALL,
> 
>         /* add new constants above here */
>         __HWTSTAMP_FILTER_CNT
> };

There is also some documentation available at 
Documentation/networking/timestamping.rst

In particular, HWTSATAMP_FILTER_PTP_V2_EVENT must timestamp event packets.

None of the modes (even the _UDP_ ones) have supported setting the 
specific UDP port.

The current uAPI requires that you must timestamp at least what the 
filter indicates, but may timestamp more. However, there is no guarantee 
what "more" is and it is device specific behavior, each device is likely 
to implement this differently.

We could extend the uAPI to better reflect what this device is capable 
of.. but I don't think that is worthwhile. The PTP standards do not 
require those modes and I doubt any application actually wants these 
timestamps, or if they do, they actually want HWTSTAMP_FILTER_ALL (which 
the X700 series hardware does not support).

The existing code for i40e timestamps additional frames, but only PTP 
messages, and only on port 319 and port 320. It does not allow arbitrary 
timestamping, and it is not useful for PTP applications following the 
standard to timestamp the packets on port 320 nor to timestamp non-event 
messages.

Since the uAPI does not allow specifying such a case, an application 
shouldn't rely on device-specific quirk that it does timestamp those 
packets. It is not cross-device compatible. The interface explicitly 
says "event" frames and doesn't list a port or a way to select a port. 
Event messages only go on port 319 by the standard, so packets on port 
320 will not need a timestamp.

I felt it makes sense to align with what the actual uAPI requests 
instead of over-provisioning and timestamping many packets that are not 
required by the requested filter.

Powered by blists - more mailing lists