Thread (23 messages) 23 messages, 5 authors, 2026-03-05
STALE115d
Revisions (3)
  1. rfc current
  2. v2 [diff vs current]
  3. v5 [diff vs current]

[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]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help