On Tue, Jun 30, 2026 at 08:06:54AM -0400, Dawid Wesierski wrote:
> From: Marek Kasiewicz <[email protected]>
>
> When PTP is enabled on the ICE PMD, hardware RX timestamps are only
> applied to packets classified as IEEE 1588 (Ethertype 0x88F7). This
> prevents applications from obtaining hardware timestamps on regular
> UDP/IP traffic.
>
> Remove the TIMESYNC packet type filter so that all received packets
> get hardware timestamps when PTP is enabled. This is required for
> time-sensitive networking applications that need per-packet arrival
> timing on media traffic, such as ST 2110-21 receiver compliance
> monitoring.
>
> The change affects all three RX paths: scan, scattered, and single
> packet receive functions.
>
> Signed-off-by: Marek Kasiewicz <[email protected]>
> Signed-off-by: Dawid Wesierski <[email protected]>
> ---
> drivers/net/intel/ice/ice_rxtx.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/intel/ice/ice_rxtx.c
> b/drivers/net/intel/ice/ice_rxtx.c
> index c4b5454c53..8d709125f7 100644
> --- a/drivers/net/intel/ice/ice_rxtx.c
> +++ b/drivers/net/intel/ice/ice_rxtx.c
> @@ -2023,8 +2023,7 @@ ice_rx_scan_hw_ring(struct ci_rx_queue *rxq)
> pkt_flags |= rxq->ts_flag;
> }
>
> - if (ad->ptp_ena && ((mb->packet_type &
> - RTE_PTYPE_L2_MASK) == RTE_PTYPE_L2_ETHER_TIMESYNC))
> {
> + if (ad->ptp_ena) {
Dropping this condition means that all packets are now marked as PTP
packets, even though they are not, which is incorrect. At minimum we need
to check the packet type before setting the PTP flag on them.
However, at a higher level again, I think if we want timestamps for all
packets that that should be a separate feature from PTP support, which
should be more limited in scope. I see there is already an
RTE_ETH_RX_OFFLOAD_TIMESTAMP block above this in the code - does specifying
that offload flag not cause all packets to get properly timestamped? If
not, I would suggest that that be enhanced rather than pretending all
packets are PTP. If that doesn't work, do we need a third alternative,
perhaps?
Regards,
/Bruce
> rxq->time_high =
> rte_le_to_cpu_32(rxdp[j].wb.flex_ts.ts_high);
> mb->timesync = rxq->queue_id;
> @@ -2390,8 +2389,7 @@ ice_recv_scattered_pkts(void *rx_queue,
> pkt_flags |= rxq->ts_flag;
> }
>
> - if (ad->ptp_ena && ((first_seg->packet_type & RTE_PTYPE_L2_MASK)
> - == RTE_PTYPE_L2_ETHER_TIMESYNC)) {
> + if (ad->ptp_ena) {
> rxq->time_high =
> rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high);
> first_seg->timesync = rxq->queue_id;
> @@ -2881,8 +2879,7 @@ ice_recv_pkts(void *rx_queue,
> pkt_flags |= rxq->ts_flag;
> }
>
> - if (ad->ptp_ena && ((rxm->packet_type & RTE_PTYPE_L2_MASK) ==
> - RTE_PTYPE_L2_ETHER_TIMESYNC)) {
> + if (ad->ptp_ena) {
> rxq->time_high =
> rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high);
> rxm->timesync = rxq->queue_id;
> --
> 2.47.3
>
> ---------------------------------------------------------------------
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII
> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP
> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
> Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy
> z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w
> transakcjach handlowych.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
> moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
> wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
> jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended recipient,
> please contact the sender and delete all copies; any review or distribution
> by others is strictly prohibited.
>
