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

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

On 2026-10-05 14:16:45 [+0200], Daniel Machon wrote:
> Sebastian,
Hi Daniel,

> Do any drivers need to be updated as part of this series?

Only in the offloaded case where PTP is intended.

> A number of drivers offload HSR duplication using NETIF_F_HW_HSR_DUP. For a
> directed PTP frame the HSR layer only sends it to the requested tx_port, but
> that is undone further down the stack (e.g. dsa_xmit_port_mask() adds the HSR
> partner port back, and icssg sends it as undirected), so e.g. a SYNC frame sent
> to port B would also leave on port A. Or am I missing something?

Before this series PTP did not work with HSR/PRP in a meaningful way. I
do have here icssg patches but there is no DSA involved. The icssg
driver tells the firmware to not duplicate "this" packet (once it
figured out it is PTP and it does HSR ) while sending and the firmware
needs to avoid automatically (as in cut-through) forward PTP packets it
received on one port to the other. This also requires firmware updates
if I remember correctly.
So yes, these changes need to happen if support is needed.
Looking at dsa_xmit_port_mask() I think it should not add additional
ports if it is a skb packet. It feels like you could avoid the loop if
HSR is not configured but enabled by add an "if (_hsr)" to
dsa_hsr_foreach_port() before the list_for_each_entry() loop.

There are also 1step capable devices which write the PTP timestamp into
the packet while it is sent. This won't work if it is not possible to
adjust the offset due to the HSR header.

> > 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
> > but does not do it for PTP packets.
> > It has not been tested within an environment where the HW is able to
> > forward the PTP packet and correctly update the timing information.
> 
> We support PTP over HSR downstream on lan969x and lan9645x (with a different
> uAPI). Maybe I can be of assistance testing this. Let me know.

Sure. I posted userland patches for linuxptp but didn't get much
feedback. I have the feeling that they wait until the kernel part is in.
I make a mental note to put you on Cc: once I repost them.

> /Daniel

Sebastian