Re: [PATCH net-next v4] hsr: Allow to send a specific port and with HSR header
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2026-05-22 12:23:17
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