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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Felix Maurer wrote:
> On Tue, Feb 17, 2026 at 05:10:53PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2026-02-16 17:10:38 [+0100], Felix Maurer wrote:
> > > I agree with Willem that the changes are pretty invasive in core parts
> > > of the stack for a pretty narrow use case. It got me thinking what would
> > > already be supported at the moment without any changes in the kernel or
> > > pretty small changes. For that, I see three parts:
> > >
> > > 1. Userspace needs to get the full HSR+PTP frames including the headers
> > >    and including the rx port information.
> > >      a) Userspace should have a way to _only_ receive HSR+PTP frames
> > >         instead of all traffic on one of the ports.
> > > 2. We should not forward HSR+PTP frames in HSR interface to prevent
> > >    creating inaccurate timing information.
> > > 3. Userspace needs a way to send packets a) over just port A or B of an
> > >    HSR interface, that b) already include an HSR header and should
> > >    therefore go mostly unmodified.
> > >
> > > Is that about a correct summary?
> >
> > 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?
> 
> > > 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).
> 
> [...]
> > > The other thing that came to my mind: this sounds like XDP with AF_XDP
> > > could be a solution that could be used already today; not so much
> > > because of their speed but because you can program what goes to the
> > > stack and what ends up in userspace. It fulfills 1) + a) directly, 2)
> > > implicitly by not letting these frames enter the stack, and 3) directly.
> > > But I also see that handling AF_XDP sockets in userspace is quite some
> > > work to do if all you really need is to separate out some traffic.
> >
> > Not forwarding PTP traffic needs to happen unconditionally and not to
> > wait until the system is up and has the software running.
> 
> I agree that we should just do that in the kernel, no matter what else
> we do to support PTP.
> 
> > 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.

Could you use existing SO_MARK? Optionally per packet with
sock_cmsg_send. And use that in hsr_forward_do if set.

Or perhaps skb->queue_mapping. For instance with tc BPF, see commit
74e31ca850c1 ("bpf: add skb->queue_mapping write access from tc
clsact").