From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
netdev@vger.kernel.org
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Felix Maurer <fmaurer@redhat.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH RFC net-next 1/2] hsr: Allow to send a specific port and with HSR header
Date: Wed, 04 Feb 2026 12:30:47 -0500 [thread overview]
Message-ID: <willemdebruijn.kernel.2d4b5c08dd442@gmail.com> (raw)
In-Reply-To: <20260204-hsr_ptp-v1-1-b421c69a77da@linutronix.de>
Sebastian Andrzej Siewior wrote:
> HSR forwards all packets it received on slave port A to slave port B and
> one of the possible two copies to the user (master) interface.
> In terms of PTP this is not good because the latency introduced by
> forwarding makes the timestamp in the PTP packet inaccurate.
>
> Introduce a hsr_ptp field to struct skb_shared_info which can be used to
> store HSR specific information for sending and receiving skbs.
>
> Receive (slave ports):
> - HSR_PT_SLAVE_A/ HSR_PT_SLAVE_B to denote the port which received the
> packet. This information is only added to PTP packets.
>
> Send (master port):
> - HSR_PT_SLAVE_A/ HSR_PT_SLAVE_B to denote the port on which the packet
> has to be sent.
> - HSR_SKB_INCLUDES_HEADER to denote that the packet already contains a
> HSR header and the stack must not add the system's header to it.
>
> HSR_SKB_INCLUDES_HEADER is used to allow forwarding a PTP packet and
> preserving the HSR header by the sender.
> Cloning skbs requires to preserve the socket information so that a PTP
> timestamp can be associated with the socket.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> include/linux/if_hsr.h | 2 +
> include/linux/skbuff.h | 1 +
> net/hsr/hsr_device.c | 7 +++
> net/hsr/hsr_forward.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++---
> net/hsr/hsr_slave.c | 16 +++++++
> 5 files changed, 133 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/if_hsr.h b/include/linux/if_hsr.h
> index f4cf2dd36d193..1463ddbc8cddf 100644
> --- a/include/linux/if_hsr.h
> +++ b/include/linux/if_hsr.h
> @@ -22,6 +22,8 @@ enum hsr_port_type {
> HSR_PT_PORTS, /* This must be the last item in the enum */
> };
>
> +#define HSR_SKB_INCLUDES_HEADER (1 << 4)
> +
> /* HSR Tag.
> * As defined in IEC-62439-3:2010, the HSR tag is really { ethertype = 0x88FB,
> * path, LSDU_size, sequence Nr }. But we let eth_header() create { h_dest,
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 86737076101d4..52c847e490ee8 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -605,6 +605,7 @@ struct skb_shared_info {
> };
> unsigned int gso_type;
> u32 tskey;
> + u32 hsr_ptp;
skb_shared_info cannot easily be expanded.
This is too specific a use-case to warrant fields in every packet.
I'm not super familiar with High-availability Seamless Redundancy
(HSR). Perhaps you can use either an skb_extension. Or the skb->cb[]
field if this data is only needed within the HSR protocol logic, so
can be assured to not be overwritten by other users of the control
block.
next prev parent reply other threads:[~2026-02-04 17:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 11:24 [PATCH RFC net-next 0/2] hsr: Add additional info to send/ receive skbs Sebastian Andrzej Siewior
2026-02-04 11:24 ` [PATCH RFC net-next 1/2] hsr: Allow to send a specific port and with HSR header Sebastian Andrzej Siewior
2026-02-04 17:30 ` Willem de Bruijn [this message]
2026-02-17 15:36 ` Sebastian Andrzej Siewior
2026-03-04 14:58 ` Sebastian Andrzej Siewior
2026-03-04 15:56 ` Willem de Bruijn
2026-03-04 16:12 ` Sebastian Andrzej Siewior
2026-03-04 23:48 ` Willem de Bruijn
2026-03-05 8:07 ` Sebastian Andrzej Siewior
2026-03-05 14:41 ` Jakub Kicinski
2026-03-05 15:05 ` Sebastian Andrzej Siewior
2026-02-04 11:24 ` [PATCH RFC net-next 2/2] af_packet: Add port specific handling for HSR Sebastian Andrzej Siewior
2026-02-04 17:36 ` Willem de Bruijn
2026-02-17 15:51 ` Sebastian Andrzej Siewior
2026-02-16 16:10 ` [PATCH RFC net-next 0/2] hsr: Add additional info to send/ receive skbs Felix Maurer
2026-02-16 16:19 ` Sebastian Andrzej Siewior
2026-02-16 16:25 ` Andrew Lunn
2026-02-17 16:14 ` Sebastian Andrzej Siewior
2026-02-17 16:10 ` Sebastian Andrzej Siewior
2026-02-18 19:28 ` Felix Maurer
2026-02-18 21:53 ` Willem de Bruijn
2026-02-24 11:48 ` Sebastian Andrzej Siewior
2026-02-24 11:24 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willemdebruijn.kernel.2d4b5c08dd442@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fmaurer@redhat.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox