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-10 17:35:33 [-0400], Willem de Bruijn wrote:
> > > but the problem was sending with system's HSR header.
> > >
> > > > For the first case, could skb->mark be used as port selector when
> > > > writing from a packet socket to the master device? That already works
> > > > with sock_cmsg_send.
> > > 
> > > We would have to specify that SO_MARK 1 and 2 denotes the port on which
> > > a packet is sent. This kind of burns the usage for everything else on
> > > HSR so it feels misused.
> > 
> > It is more or less what mark is for. An alternative similar field
> > supported by sock_cmsg_send is skb->priority.
> 
> The ->priority thing looks wrong. It is used by ssh and other
> application so they would suddenly behave differently.
> But okay lets take SO_MARK. Might be smallest abuse here.
> And we would have to hardcode the values in respect to HSR and I have no
> idea where to document this.
> The difference with SO_MARK in general (at least my understanding) is
> that you can choose the values based on your setup. Here we would say
> 7-0 are already reserved.
> 
> > An alternative may be to share the information in-band. Already
> > insert the HSR header also wen writing to the master device. If the
> > master device can detect this packet-with-pre-existing header.
> 
> Given all this, I guess it is easier to stick to SO_MARK as the header
> might collide with other data.

Inserting a header by the packet socket sender and popping it in
hsr_dev_xmit is a bit like virtio_net. It is a private channel.

The tricky part is how hsr_dev_xmit can differentiate such packets
inserted by a packet socket, from regular packets arriving on the
device.

Anyway, admittedly it is a bit of a hack too.


> > This is not the first case where ndo_start_xmit may already expect a
> > header prefixed that it normally inserts. I forgot the exact case (can
> > look it up), maybe a weird edge case in GRE?
> > 
> > It does not even have to be a valid HSR header: just an agreement
> > between the process writing the raw packet and hsr_dev_xmit.
> > 
> > There probably are still more ways we can approach this challenge.
> > But these are three that do not require kernel changes outside the
> > HSR protocol code.
> 
> Okay.
> 
> > > And then we would need an additional bit to
> > > specify whether the HSR header is there or not. Unless I open additional
> > > socket on the ethernet device just for sending and dropping everything
> > > incoming.
> > 
> > Right, packets that already have a header prefixed are written
> > directly to the intended slave.
> > 
> > > And we would have to filter/ distinguish the RX port based on it.
> > > Userland has a cBPF filter to filter everything out and receive only PTP
> > > frames. If the PTP packet is forwarded to both sockets (A and B) then
> > > userland would have to throw one copy away and go to sleep again. This
> > > sort of breaks currently linuxptp logic. It would probably require
> > > either eBPF to filter also so_mark or deal with "no packet despite the
> > > wakeup" but so far I tried minimal impact on both sides (kernel and
> > > user).
> > 
> > I don't fully follow this part. It discusses Rx again?
> 
> 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.

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