Thread (7 messages) 7 messages, 4 authors, 20d ago

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help