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-03-13 10:22:28 [+0100], To Willem de Bruijn wrote:
> > On 2026-03-12 17:43:36 [-0400], Willem de Bruijn wrote:
> > > > Yes, this is RX. If I open packet socket, bind to hsr0, how do I filter
> > > > for packets from one of the slaves?
> > > 
> > > I was thinking of attaching directly to the slave devices.
> > 
> > That could work. Let me see.
> 
> Halfway done. What we went down to is:
> 
> Send with header    -> eth0/ eth1 + SO_MARK for header + port 1/ 2
> Send without header -> hsr0 + SO_MARK 1/2 port 1/ 2 
> RX                  -> listen on eth0/ eth1
> 
> Now this compiles and I look into userland and am currently stuck with
> the problem that it does not expect "two devices". It is not impossible
> but…
> 
> > > > After some thinking and browsing through the packet code:
> > > > The hsr stack creates hsrX. If it would create additionally hsrX_A and
> > > > hsrX_B in order to be able to send and receive only on the relevant
> > > > slave device then I wouldn't need the filters in packet code. That could
> > > > work…
> > > 
> > > That's another option.
> > 
> > Okay. Let me add this as plan B then.
> 
> At this point I am considering this which would avoid having to use
> hsr0+eth1 for one direction depending on whether I have to send with or
> without the header. But this might lead to other problems such as ip
> address and so on.
>  
> The suggested changes to af_packet, that remains a hard no?

Yes. Packet sockets are largely superseded by XDP and AF_XDP when it
comes to new functionality. And were never open for such protocol
specific logic.

Protocol independent extensions, such as reading skb->mark as part of
extended auxdata, could be up for debate. But again, we already have
XDP and AF_XDP which allow passing arbitrary metadata to/from
userspace. That is preferable over adding new structs to the ABI.

If you only want to attach to a single (hsr0) device, I still think
passing the data inline might work. Either by overriding existing
fields such as a MAC addr (a hack for sure) or something in the HSR
header (it as the direction? or by inserting a custom header (or
trailer) akin to virtio_net_hdr for tun/tap. But custom to your
workload.