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

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

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.

> 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
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