# Re: \[PATCH RFC net-next 0/2\] hsr: Add additional info to send/ receive skbs

- From: Sebastian Andrzej Siewior \<bigeasy@linutronix.de\>
- Date: 2026-02-24 11:24:49 
- List: netdev
- Page: https://ratatoskr.run/netdev/2026/02/11348463
- Thread: https://ratatoskr.run/netdev/2026/02/11347174/t.md

```text
On 2026-02-18 20:28:36 [+0100], Felix Maurer wrote:
> > Yes. Point 3b needs to be extended by
> >   " + or does not contain a HSR/PRP header and requires one by the
> >   system."
> 
> Ah, I missed that! Thanks for pointing it out, that seems to be the
> tricky part to me. Just be sure, you refer to the Pdelay_{Req,Resp}
> messages? Or are there any other messages?

These and the SYNC+FOLLOW_UP if the node is master.

> > > If I understand your patch 2 correctly, you will be maintaining two
> > > sockets in userspace (one bound to each of the ports A and B through the
> > > HSR interface using PACKET_HSR_BIND_PORT). Binding through the HSR
> > > interface to port A/B has the very special meaning of making a socket
> > > only receive a very small subset of the packets, that is PTP traffic at
> > > the moment. This seems like a somewhat hidden property of the bound
> > > sockets and should at least be very explicit.
> >
> > Technically four sockets (two for A and two for B) but in general yes.
> > What you mean by hidden property/ very explicit? Document
> > PACKET_HSR_BIND_PORT in packet(7) or something else?
> 
> Yes, at least that. Maybe also make it more clear in the name that this
> kind of binding means that you will not receive all packets from this
> port but just some (atm, PTP).

Right. That happens implicit because they are not tagged. Extending the
present documentation would be something I consider once we do align on
something.

> > However if we
> > ignore this detail and can receive on interface A and send on interface
> > B over XDP and get timestamps right then we have the same as the packet
> > interface on the two eth devices. What is missing is sending with HSR/
> > PRP header.
> 
> You wrote in another reply, and I agree with it, that sending with the
> system HSR header and sequence number must go through the hsr device.
> Frames that already have a header, such as Sync an FollowUp that are
> forwarded, could just directly go through the slave interfaces.
> 
> I think the cases should be handled independently: to send a frame with
> a full header (i.e., the forward case), we already have the AF_PACKET
> socket on the slave interfaces as an option. For sending a frame just in
> one direction in the HSR ring through the hsr interface, we have to come
> up with something, but IMHO just for that.
> 
> I like the idea of putting the port hint in the ancillary data of the
> message, but I'm not sure where to put in the skb then / how to pass it
> to the hsr interface. Willem's suggestions are worth exploring I think.

Good. I will try to come up with something. Willem had something, I will
look into this.

> Thanks,
>    Felix

Sebastian
```