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

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

On 2026-02-04 12:36:36 [-0500], Willem de Bruijn wrote:
> > --- a/net/packet/af_packet.c
> > +++ b/net/packet/af_packet.c
> > @@ -2131,6 +2168,13 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
> >  	if (!net_eq(dev_net(dev), sock_net(sk)))
> >  		goto drop;
> >  
> > +	if (po->hsr_bound_port) {
> > +		struct skb_shared_info *si = skb_shinfo(skb);
> > +
> > +		if (po->hsr_bound_port != si->hsr_ptp)
> > +			goto drop;
> > +	}
> > +
> 
> Similar to the high level comment to patch 1/2: this is quite a rare
> use case, but this implementation imposes cost on every user. By
> adding branches in the hot path, among others.
> 
> It is simply not scalable to extend core infra in this way for every
> use case. The cross product of features is too great. We'll have to
> find a way that is less HSR specific.
> 
> There are existing mechanisms for binding to a specific interface or
> port, such as SO_BINDTOIFINDEX and packet bind().

Would a static_branch_unlikely() be okay to have it off by default and
only enable once there is at least one user doing it?

I do
   setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, name, strlen(name))

which is probably the same thing. With this I get to the "hsr0" device.
The hsr device has two slave ports which are hidden from the user in
general and only copy gets passed. For PTP I need to know which (PTP)
packet was received on the individual port. This is purpose of it. So I
have one fd for port A and one fd port B. (+ timestamps).

For the RX side I could simply use that device directly instead of the
hsr device.
But for TX I need to send a PTP packet with system's HSR header
(including the HSR-sequence number). I don't know how to achieve this
without using the hsr device. And the packet must not be sent on both
ports (like it is usually the case) but only on one of the ports (either
A or B).

Sebastian