All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org,  Andrew Lunn <andrew+netdev@lunn.ch>,
	 Chintan Vankar <c-vankar@ti.com>,
	 Danish Anwar <danishanwar@ti.com>,  Daolin Qiu <d-qiu@ti.com>,
	 "David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	 Felix Maurer <fmaurer@redhat.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Neelima Muralidharan <neelima@ti.com>,
	 Paolo Abeni <pabeni@redhat.com>,
	 Praneeth Bajjuri <praneeth@ti.com>,
	 Pratheesh Gangadhar TK <pratheesh@ti.com>,
	 Richard Cochran <richardcochran@gmail.com>,
	 Simon Horman <horms@kernel.org>,
	 Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH RFC net-next v3] hsr: Allow to send a specific port and with HSR header
Date: Mon, 04 May 2026 13:08:04 -0400	[thread overview]
Message-ID: <willemdebruijn.kernel.22897601ad5fe@gmail.com> (raw)
In-Reply-To: <20260504085911.nLZLRjPF@linutronix.de>

> > > +#define HSR_INLINE_HDR	0xaf485352
> > > +struct hsr_inline_header {
> > > +	uint8_t tx_port;
> > > +	uint8_t hsr_hdr;
> > > +	uint8_t __pad0[4];
> > > +	uint32_t magic;
> > > +	uint8_t __pad1[2];
> > > +	uint16_t eth_type;
> > > +} __packed;
> > > +
> > 
> > No specific need to make this header ethhdr like?
> 
> What do you mean? eth_type is at the same spot or do you mean it should
> be named h_proto?

I mean there is no reason your fake header needs to be 14B or
or otherwise resemble an Ethernet header.

That ties into my last comment to use sizeof(struct hsr_inline_header)
where working with that header, rather than ETH_HLEN. It is an
independent header.

This padding and packing is unnecessary.

> > > diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
> > > index 5555b71ab19b5..ac39b2347aa0f 100644
> > > --- a/net/hsr/hsr_device.c
> > > +++ b/net/hsr/hsr_device.c
> > > @@ -228,20 +228,51 @@ static netdev_tx_t hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
> > >  
> > >  	rcu_read_lock();
> > >  	master = hsr_port_get_hsr(hsr, HSR_PT_MASTER);
> > > -	if (master) {
> > > -		skb->dev = master->dev;
> > > -		skb_reset_mac_header(skb);
> > > -		skb_reset_mac_len(skb);
> > > -		spin_lock_bh(&hsr->seqnr_lock);
> > > -		hsr_forward_skb(skb, master);
> > > -		spin_unlock_bh(&hsr->seqnr_lock);
> > > -	} else {
> > > -		dev_core_stats_tx_dropped_inc(dev);
> > > -		dev_kfree_skb_any(skb);
> > > +	if (!master)
> > > +		goto drop;
> > > +
> > > +	skb->dev = master->dev;
> > > +	if (skb->len > ETH_HLEN * 2) {
> > > +		struct hsr_inline_header *hsr_opt;
> > > +
> > > +		BUILD_BUG_ON(sizeof(struct hsr_inline_header) != sizeof(struct ethhdr));
> > > +		hsr_opt = (struct hsr_inline_header *)skb_mac_header(skb);
> > > +		if (hsr_opt->eth_type == htons(ETH_P_1588) &&
> > > +		    hsr_opt->magic == htonl(HSR_INLINE_HDR)) {
> > > +			enum hsr_port_type tx_port;
> > > +			bool has_header;
> > > +
> > > +			has_header = hsr_opt->hsr_hdr;
> > > +			tx_port = hsr_opt->tx_port;
> > > +			if (tx_port != HSR_PT_SLAVE_A && tx_port != HSR_PT_SLAVE_B)
> > > +				goto drop;
> > > +
> > > +			if (!hsr_skb_add_header_port(skb, has_header, tx_port))
> > > +				goto drop;
> > 
> > All use of this information happens in the context of this ndo_start_xmit?
> 
> I receive it from af_packet in HSR's ndo_start_xmit, yes. Then
> hsr_xmit() is forwarding it to the slave device via dev_queue_xmit().
> Here the skb->cb information gets overwritten.
> 
> I need this hint in the slave eth driver in case there is hsr-offloading
> available. 

This assumes that the slave device is somehow HSR aware. But standard
net_devices are not?

Isn't it HSR's ndo_start_xmit that selects which slave to forward to,
based on the information in this header?

  reply	other threads:[~2026-05-04 17:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29 14:01 [PATCH RFC net-next v3] hsr: Allow to send a specific port and with HSR header Sebastian Andrzej Siewior
2026-04-29 17:46 ` Willem de Bruijn
2026-05-04  8:59   ` Sebastian Andrzej Siewior
2026-05-04 17:08     ` Willem de Bruijn [this message]
2026-05-05  9:52       ` Sebastian Andrzej Siewior
2026-05-05 16:14         ` Willem de Bruijn
2026-05-06  7:09           ` Sebastian Andrzej Siewior
2026-05-06 13:20             ` Willem de Bruijn
2026-05-07 15:43               ` 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.22897601ad5fe@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bigeasy@linutronix.de \
    --cc=c-vankar@ti.com \
    --cc=d-qiu@ti.com \
    --cc=danishanwar@ti.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmaurer@redhat.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=neelima@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=praneeth@ti.com \
    --cc=pratheesh@ti.com \
    --cc=richardcochran@gmail.com \
    --cc=vigneshr@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.