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-19 09:29:44 [-0400], Willem de Bruijn wrote:
> > > But here you have PACKET_VNET_HDR_SZ to configure virtio_net_hdr. 
> > 
> > I mean an implicit header in the packet. virtio_net_hdr is something
> > that the packet socket needs to inspect. The metadata between ptp4l
> > and hsr_dev_xmit is not, so the packet socket can be oblivious to it.
> 
> Ah okay. If I insert a header, I would need to scan for something in
> every packet and it must not collide with anything that would include
> the same sequence.

True.

> This means the PTP packets from ptp4l and everything
> else that sends data. That is something I am not very comfortable with.
> Even the destination MAC address had to be changed a few times during
> testing so scanning for it would not be good.
> 
> > > This
> > > is kind of what I ask for with PACKET_HSR_INFO + PACKET_HSR_BIND_PORT
> > > (and I added static branches so nobody has to suffer with CONFIG_HSR
> > > enabled but no HSR enabled socket)..
> > > 
> > > The diff below would be what means to bypass AF_PACKET entirely and use
> > > eth0/ eth1 to send via SLAVE_A/ B and hsr0 with SO_MARK to send with
> > > system's HSR header but only on one of the two ports.
> > > With HSR-offloading enabled we need to attach the SO_MARK hints also on
> > > eth0/ eth1 devices, too. Otherwise the offloading part will send the
> > > packet on both ports and attach a header (as designed).
> > 
> > eth0/eth1 are not HSR devices, so how would they interpret skb->mark
> > and how would they loop packets to the other port?
> 
> If you look at the diff below, there is the
> hsr_skb_get_header_port_mark() helper.
> 
> So eth0/ eth1 are not HSR devices but they are used as slaves by hsr0.
> The intention is use the eth0/ eth1 devices to pass packets which
> include the HSR-header. So if I send on eth0 the intention is to send
> the packet 1:1 on this device. The skb->mark is not required there
> unless with hardware offload enabled. 

Right, so this is simple without hardware offload. Does this HW
offload exist, or is this aspirational. At least for infrequent PTP
it does not sound important.

> In this case if "PORT" marker is
> used to let the driver know to not duplicate the packet on the other
> port and if "HEADER" marker is set then it won't prepend a HSR header.
> The port marking is the same as for hsr0 and I used the next bit for the
> header to keep things a bit simple.
> The skb->mark with values 1…7 is then not available to anything else in
> this scenario.
> 
> > > diff --git a/drivers/net/ethernet/ti/icssg/icssg_common.c b/drivers/net/ethernet/ti/icssg/icssg_common.c
> > > index 79df641b4fb97..a2e50cae01686 100644
> > > --- a/drivers/net/ethernet/ti/icssg/icssg_common.c
> > > +++ b/drivers/net/ethernet/ti/icssg/icssg_common.c
> > > @@ -909,13 +909,17 @@ enum netdev_tx icssg_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev
> > >  	 */
> > >  	dst_tag_id = emac->port_id | (q_idx << 8);
> > >  
> > > -	if (prueth->is_hsr_offload_mode &&
> > > -	    (ndev->features & NETIF_F_HW_HSR_DUP))
> > > -		dst_tag_id = PRUETH_UNDIRECTED_PKT_DST_TAG;
> > > +	if (prueth->is_hsr_offload_mode) {
> > > +		bool has_header;
> > > +		bool has_port;
> > >  
> > > -	if (prueth->is_hsr_offload_mode &&
> > > -	    (ndev->features & NETIF_F_HW_HSR_TAG_INS))
> > > -		epib[1] |= PRUETH_UNDIRECTED_PKT_TAG_INS;
> > > +		hsr_skb_get_header_port_mark(skb, &has_header, &has_port);
> > > +		if (ndev->features & NETIF_F_HW_HSR_DUP && !has_port)
> > > +			dst_tag_id = PRUETH_UNDIRECTED_PKT_DST_TAG;
> > > +
> > > +		if (ndev->features & NETIF_F_HW_HSR_TAG_INS && !has_header)
> > > +			epib[1] |= PRUETH_UNDIRECTED_PKT_TAG_INS;
> > > +	}
> > >  
> > >  	cppi5_desc_set_tags_ids(&first_desc->hdr, 0, dst_tag_id);
> > >  	k3_udma_glue_tx_dma_to_cppi5_addr(tx_chn->tx_chn, &buf_dma);
> 
> Sebastian