Re: [PATCH RFC net-next 1/2] hsr: Allow to send a specific port and with HSR header

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

On 2026-03-05 06:41:11 [-0800], Jakub Kicinski wrote:
> On Thu, 5 Mar 2026 09:07:31 +0100 Sebastian Andrzej Siewior wrote:
> > Let me redo this with the skb-extension variant. 
> 
> Expect opposition. HSR is an Orphan full of trouble already and what

it might be an orphan but the handling of sequence numbers reworked
recently.

> you're trying to do very much feels like a one off hack to me.

It specific support for PTP support over HSR/PRP, yes. So nothing else
benefits from it.

> Can't the Tx path be done with an egress redirect on the HSR upper?

For the RX side I need to know which port received the PTP packet and
forward this information to userland along with a possible PTP
timestamp and ensure the HSR stack does not forward the packet on the
other port.

For the TX side I need to be able to send the packet on one of the two
ports, be able to let the HSR stack create a HSR header or use the
provided header which should not be used for any checks (de-duplication
and so on) while sending it. Here is also the possible PTP timestamp.

If it wouldn't be for the HSR frame header on the TX side where the
packets originate from the node (sending PTP SYNC, PDELAY_* and so on)
then I could directly attach to the two slave devices.

Sebastian