Re: [PATCH net-next v9 0/8] hsr: Add additional info to send/ receive skbs

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-10-16 11:01:04 [+0200], Daniel Machon wrote:
> Hi Sebastian,
Hi Daniel,

> > I am trying to extend linuxptp to support PTP over a HSR network.
> > 
> > This is the kernel side of the changes. In short PTP over HSR sends its
> > packets to a 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 do 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.
> 
> I think the main reason is that PTP over HSR needs per-path delays, so packets
> have to be steered out a specific ring port.

not only that but the time, the packet was in transit, needs to be
accounted for.

> > 
> > My current approach is to open the slave devices (eth0/ eth1) from
> > userland in order to receive the PTP packets. Sending happens from the
> > hsr0 device. The actual packet has an inline header prepended of type
> > struct hsr_inline_header. The size of the header is equivalent to
> > ethhdr. The header has a type (h_proto) at the same position as ethhdr
> > and expects it to be ETH_P_1588 as this extra meta information is only
> > relevant for PTP packets. It makes no sense to send PTP packets via the
> > HSR interface because it gets duplicated and the timestamp information
> > is lost so this should not break anything. As an additional safe guard
> > there is a magic value at h_source position. The value has '0xaf' at the
> > most significant byte which makes the address a locally administered
> > multicast address.
> > 
> > The header passes two information from userland: On which slave port
> > the packet has to be sent and does the HSR stack need to prepend a
> > header or not.
> 
> It was not entirely clear to me that hsr_hdr=1 meant "this frame already carries
> an HSR tag" as opossed to "please add one".

Is this English bad and must be changed or just a note?

> > The header is skipped so that the remaining stack sees the actual data
> > and can send it as requested.
> > 
> > The PRP packets are sent directly via the SLAVE interface. The standard
> > mandates not add a PRP trailer (PRP, redundancy control trailer) to PTP
> > packets. There is not really a reason to use hsr interface.
> > 
> > HSR hardware offloading is optional. The driver needs to know if the
> > operating mode is HSR or PRP. In PRP mode it needs to check the ether
> > type and for ETH_P_1588 it must not perform any offloading.
> > In HSR mode, for ether-type ETH_P_1588 there must be no offloading. If
> > the ether-type is ETH_P_HSR there must be no offloading if the
> > encapsulated protocol is ETH_P_1588.
> 
> I think my question on v8 still stands: some existing drivers will undo the
> directed TX. Should they be updated to check for PTP frames? I am not sure
> myself.

I though my answer was clear, sorry it it was not. The drivers with HSR
offload support need to be updated to get the PTP part properly to work.
They didn't before so it is not a regression. I can't do it all at once.
Once this it through I plan to look into the icssg driver. I can help
with DSA stack but I have no HW around.

> > This has been tested in a pure software environment and in an HW-assisted
> > environment where the HW is able to duplicate and duplicate packets
> 
> s/duplicate and duplicate/duplicate and deduplicate/

oki…

> >
> 
> nit: the subject for the cover letter says little about the patchset, maybe that
> could be updated.

I see. The subject? So I have "Add additional info to send/ receive
skbs" from v1. I don't have the receive part anymore due requested
changes. The send is still accurate. Any wishes?

> /Daniel

Sebastian