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

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

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.

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

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…

Sebastian