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/[email protected]/
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.
