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

Sebastian Andrzej Siewior
2026-03-19T14:26:16Z

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