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

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

On 2026-05-21 20:22:11 [+0200], Felix Maurer wrote:
> Hi Sebastian,
Hi Felix,

> 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.

The inline header is the common ground I established with Willem.

> 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.

We would have to invent this flag and then af_packet would have to use
it. In its current shape, we need to look at skb->protocol and is
restricted to the PTP case. This shouldn't cause too much overhead.

> 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?

Okay. Sounds reasonable.

> Thanks,
>    Felix

Sebastian