On 2026-02-18 20:28:36 [+0100], Felix Maurer wrote:

quoted

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.

quoted

quoted

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.

quoted

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