Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR

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

Sebastian Andrzej Siewior wrote:
> On 2026-04-06 10:47:56 [-0400], Willem de Bruijn wrote:
> Hi Willem,
> 
> > So the requirement is for a communication path between userspace and
> > the driver over packet sockets.
> > 
> > Existing options that work for both rx and tx are
> > 
> > - in-band: a packet header or footer
> > - mark, metadata
> > - maybe: vlan tags
> > 
> > These require changes in the HSR driver to use them, but no changes in
> > the protocol independent core logic, which includes packet sockets.
> > 
> > As I mentioned before we cannot sprinkle protocol specific code
> > throughout protocol independent core code. That quickly leads to an
> > unmaintainable mess. PTP over HSR is a particular small niche case,
> > nowhere near first in line to get an exception to this guideline.
> 
> I understand your concern. I tried to make as self contained as
> possible and little runtime overhead as possible.
> 
> > One perhaps interesting Rx only option I had missed before is
> > SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
> > device ifindex today?
> 
> The upper logic expects to poll() on the fd. If I need to filter the
> device based on this then breaks the expectations.
> I need also to receive packets without a timestamp so I don't think this
> works.

I don't follow this. My suggestion is to optionally receive this
additional metadata along with the data. Not as a filter.
 
> > If so, we now only have to consider the Tx path to the HSR driver
> > (the Tx path directly to the other drivers do not need this metadata).
> > 
> > I'm not convinced that it is hard to come up with a way to send
> > a packet to the HSR driver with an optional header or footer or
> > vlan data (or skb->protocol perhaps?) that cannot be
> > differentiated from other traffic arriving at that ndo_start_xmit.
> 
> I've been looking to skb->protocol. Maybe if the packet has ether type
> set to PTP then the HSR layer could consider everything before it (the
> two MAC address fields) as internal header and the actual packet starts
> after that. Reasoning would be that you shouldn't send a PTP packet over
> HSR without dealing with the restrictions. So this could work.
> 
> Then the question remains how to do the filtering on RX side. For the
> so_mark I did open additional two sockets…
> 
> > If all this fails, we can look into a protocol independent approach
> > to passing other metadata in packet sockets. to/from skb_ext or cb[],
> > say.
> 
> I will try the above but it looks very hackish.
> cb[] is limited to one layer. I do have a skb_ext variant working but
> this requires cmsg to set it. Do you think about generic skb_ext which
> is set from af_packet? But I don't think it brings much value if I can't
> filter on the RX side before returning the packet to userland.
> 
> > But at this point I see enough options that do not require changes
> > to packet sockets.
> > 
> > To get back to the simplest approach: skb->mark. Is there any
> > concrete risk that on this path that would conflict with other
> > uses of that field? If packet sockets inject directly into this
> > driver (possibly even with PACKET_QDISC_BYPASS)?
> 
> So I have a skb->mark variant working. I do read on the ethX interface

When reading on both ethX interfaces, that gives you all the info you
need on Rx, right? Or alternatively by attaching to hsr0 with
SOF_TIMESTAMPING_OPT_PKTINFO.

So skb->mark is only relevant to the Tx side, right? There might be
yet another way to identify in the hsr ndo_start_xmit that a packet
arrived from a PF_PACKET socket. E.g., by checking skb->sk->sk_family.
As alternative or complement to skb->protocol.

Btw, on receive the inverse could also be true: insert a synthetic
header and pop that in userspace, e.g., a VLAN tag.

> and write on the hsr0 interface (so I need two extra fd per interface).
> The only concern here is that the mark value is hardcoded and could
> collide with an existing firewall setup or so.
> This field needs also be evaluated by the ethernet driver in case of
> hw-offloading for HSR.
> So far, this is the only working solution I have which does not touch
> af_packet.
> 
> Let me try the header with the PTP hedaer type and the additional
> sockets for RX.
> It will not win a beauty contest but maybe I judge too harsh…
> 
> Sebastian