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-21 03:41:52 [-0400], Willem de Bruijn wrote:
> Sebastian Andrzej Siewior wrote:
Hi Willem,

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

Yes. Just ignore that part.

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

So I made this:
I open hsr0 for TX with a custom header. The header is expected if the
ether-type is set to PTP. This extra header holds the HSR-header
information and port request.
I open eth0 for RX. I set PACKET_IGNORE_OUTGOING to avoid the feedback
from hsr0 writes. This is part is crucial ;)

I use skb_ext to pass the information from the inline-header to
the network driver since the data pointer of the skb is forwarded after
that header. In the end I have no idea if the network driver supports HW
offloading and needs this information or not and sends the packet as-is.

HW offloading becomes a bit tricky but relying on skb_ext (for HSR) and
checking otherwise for the ether type vs PTP (in the PRP case) does the
trick.

So it is slightly more complicated but seems to work.
Let me wait until after the merge window and then I present what I have.

Sebastian