[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260204-hsr_ptp-v1-0-b421c69a77da@linutronix.de>
Date: Wed, 4 Feb 2026 12:24:02 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: netdev@...r.kernel.org
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Felix Maurer <fmaurer@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Richard Cochran <richardcochran@...il.com>,
Simon Horman <horms@...nel.org>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: [PATCH RFC net-next 0/2] hsr: Add additional info to send/ receive skbs
I am trying to extend linuxptp to support PTP over a HSR network. The
user space for linuxptp are still under discussion, the thread starts at
https://lists.nwtime.org/sympa/arc/linuxptp-devel/2025-11/msg00013.html
the posted patches are also available at git repository for convenience
https://git.kernel.org/pub/scm/linux/kernel/git/bigeasy/linuxptp-hsr.git hsr_v2
This is the kernel side of the changes. In short PTP over HSR sends its
packets to multicast address and every node needs to forward the PTP
packet (SYNC and FOLLOW-UP for instance) within the HSR ring.
In order to achieve this, the HSR stack must not duplicate and forward
the PTP packets as it would with other packets. The delay caused by the
duplication and forwarding adds overhead which in turn makes the timing
information within the PTP packet inaccurate.
My current approach is to open the hsr0 device from userland and send
and receive the PTP packets individually on both slave interfaces. I
added additional hints to the af_packet interface, which is used by
linuxptp, to be able send a packet on a specific interface (A or B) and
also to have the information recorded for received packets.
Additionally, the PTP-timestamps which arrive on the slave interface are
forwarded to the hsr interface.
This solves the following:
- Forwarding a SYNC and a FOLLOW_UP packet.
Userland receives a SYNC, FOLLOW_UP and timestamp packet from port A.
The received port is known and recorded. The SYNC sync packet and the
updated FOLLOW_UP packet can then be forwarded on port B. The update
is based on the time spent during the forward so the forwarding delay
is accounted for.
In this scenario the HSR header is used from the original sender of
the SYNC and FOLLOW_UP header and the stack must not prepand the
system's HSR header nor replace the provided header.
- Sending PDELAY_REQ and PDELAY_RESP*
These packets are only exchanged between the two nodes directly
connected and they must not be forwarded within the HSR ring.
These packets are sent as PTP packets and the HSR stack must prepand
system's HSR header including a sequence number.
This logic is also used for SYNC packet if the node acts as a GM.
This has been tested in a pure software environment and in an HW-assited
environment where the HW is able to duplicate and deduplicate packets
but does not do it for PTP packets.
It has not been tested within an enviroment where the HW is able to
forward the PTP packet and correctly update the timming information.
This series will clash with Felix's sequence number/ deduplication
rework.
---
Sebastian Andrzej Siewior (2):
hsr: Allow to send a specific port and with HSR header
af_packet: Add port specific handling for HSR
include/linux/if_hsr.h | 2 +
include/linux/skbuff.h | 1 +
include/uapi/linux/if_packet.h | 9 ++++
net/hsr/hsr_device.c | 7 +++
net/hsr/hsr_forward.c | 114 ++++++++++++++++++++++++++++++++++++++---
net/hsr/hsr_slave.c | 16 ++++++
net/packet/af_packet.c | 103 +++++++++++++++++++++++++++++++++++++
net/packet/internal.h | 1 +
8 files changed, 246 insertions(+), 7 deletions(-)
---
base-commit: 4ff7d63728ef2315d402a608cef1376248aa5c56
change-id: 20260204-hsr_ptp-1f6380f1d35f
Best regards,
--
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Powered by blists - more mailing lists