Re: [PATCH net-next v4] hsr: Allow to send a specific port and with HSR header

[Felix Maurer <fmaurer@redhat.com>]

On Fri, May 08, 2026 at 12:17:38PM +0200, Sebastian Andrzej Siewior wrote:
> HSR forwards all packets it received on slave port 1 to slave port 2 and
> one of the two copies to the user (master) interface.
> In terms of PTP this is not good because the latency introduced by
> forwarding makes the timestamp in the PTP packet inaccurate.
> The PTP packets should not be forwarded like regular packets.
>
> In order to work with PTP over HSR the following has been done:
> - PTP packets which are received are dropped within the HSR stack. That
>   means they are not forwarded or injected into the master port. If the
>   user requires them, then they need to be obtained directly from the
>   SLAVE interface.
>
> - Sending packets. If the ethernet type of the packet is ETH_P_1588 then
>   the stack assumes a header of type struct hsr_inline_header. The size
>   of this header is the same as ethhdr. As a safeguard, the header
>   contains a magic field which matches the position of h_source and it
>   needs to match HSR_INLINE_HDR.
>   Once this is verified, the header contains the port on which this
>   packet needs to be sent and if system's HSR header should be added.
>   This information is used with the HSR stack. The packet is then
>   pulled passed the custom header so the remaining stack will see the
>   actual data.
>
> - HSR HW offloading. The stack passes the skb to the requested port. The
>   driver needs to be aware of the mode (HSR/ PRP). In PRP mode, there
>   must be no offloading if the ether type is ETH_P_1588. In HSR mode it
>   needs to add a HSR header for the ETH_P_1588 ether type but none if it
>   is already ETH_P_HSR.

Hi Sebastian,

I unfortunately didn't get to properly reviewing your patch before
leaving for vacation. But in general I like what you're proposing at the
moment. The inline header feels like a bit of magic to me still, but
it's probably necessary to have some amount of magic to make the
different sending options possible. Also seems like it doesn't put too
much burden on user space.

Skimming the patch, one thing came to my mind: maybe there is a simple
way to make user space opt-in to the inline header handling, e.g.,
something like a respect-hsr-inline-header flag at socket level(?) that
only gets checked in the hsr code. Without such flag, the special
parsing wouldn't happen at all, with the flag we still check for the
inline magic value to support sending normal frames and special frames.
But this is mostly an idea, probably not too well thought through yet.

But I have one real ask: can you add a simple selftest for this? No need
to do any kind of real PTP, but just verify that we don't break any case
of the matrix "add header/includes header" x "send normally/send on
single port". Maybe just by tcpdump'ing on the other end of a veth?

Thanks,
   Felix