[PATCH RFC net-next 0/2] hsr: Add additional info to send/ receive skbs
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2026-02-04 11:24:55
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 [off-list ref]