public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Felix Maurer <fmaurer@redhat.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	jkarrenpalo@gmail.com, tglx@linutronix.de, mingo@kernel.org,
	allison.henderson@oracle.com, petrm@nvidia.com,
	antonio@openvpn.net
Subject: Re: [PATCH net-next v2 1/9] selftests: hsr: Add ping test for PRP
Date: Tue, 3 Feb 2026 12:55:26 +0100	[thread overview]
Message-ID: <20260203115526._PRE3nvY@linutronix.de> (raw)
In-Reply-To: <aYHJ9KHdiBEGfjwA@thinkpad>

On 2026-02-03 11:12:36 [+0100], Felix Maurer wrote:
> On Mon, Feb 02, 2026 at 04:55:10PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2026-02-02 12:51:12 [+0100], Felix Maurer wrote:
> > > > Hm, I am not sure? For PRP, it's an explicit requirement to use the same
> > > > MAC addresses for both ports. For HSR, I think the standard is less
> > > > clear about the MAC addresses. And at least our code seems to assume
> > > > that there could be different MACs on the two interfaces of a node? But
> > > > yes, the node merging addresses this.
> > >
> > > I'm still not 100% certain, but I agree that the standard reads more
> > > like the MAC addresses should be the same for the two HSR ports. At the
> > > moment, the kernel and the test assumes that they can/should be
> > > different. Therefore, I think we should fix this across the board in
> > > another patchset if we agree that's the right thing to do.
> >
> > I would suggest to do so. This could serve as bad example and my PTP
> > userland patches expect the same MAC on both ports. So ;)
> 
> I'll put it on my list for another patchset :)
> But this of course brings up how the MAC addresses should be handled on
> the HSR interfaces in general. At the moment, for HSR we copy the MAC of
> portA to master. For PRP, the MAC of portA is copied to master and
> portB.
> 
> If the MACs should be the same for both ports of an HSR interface,
> should we set them when creating the HSR interface, similarly to PRP?
We do this?

> And does it make sense to copy from portA (feels somewhat arbitrary to
> me) or would it be cleaner to copy from master to portA and portB?

I do
| ip link set $portA down
| ip link set $portB down
| ip link set dev $portA address $mac
| ip link set dev $portB address $mac
| ip link add name $if type hsr slave1 $portA slave2 $portB supervision 45 version 1

and then up, up, up to get up the three interfaces functional. $mac is
the MAC $portA.

On the other hand it shouldn't matter because while adding the HSR tag,
the MAC of the hsr interface should be taken but somehow I observed that
packets, which originate on the $portB interface have the MAC address of
this interface. So I did this and forgot about it later…
But then hardware offloading might behave different if it considers the
address of the interface so it might required to set the MAC address.

I am uncertain what the best practice would be here.
Forcing the MAC of portA to portB could be done at setup phase by the
stack but would require that the interface is down…

> Thanks,
>    Felix

Sebastian

  reply	other threads:[~2026-02-03 11:55 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 14:56 [PATCH net-next v2 0/9] hsr: Implement more robust duplicate discard algorithm Felix Maurer
2026-01-22 14:56 ` [PATCH net-next v2 1/9] selftests: hsr: Add ping test for PRP Felix Maurer
2026-01-29 11:05   ` Sebastian Andrzej Siewior
2026-01-29 13:31     ` Felix Maurer
2026-01-29 15:21       ` Sebastian Andrzej Siewior
2026-01-29 17:44         ` Felix Maurer
2026-02-02 11:51           ` Felix Maurer
2026-02-02 15:55             ` Sebastian Andrzej Siewior
2026-02-03 10:12               ` Felix Maurer
2026-02-03 11:55                 ` Sebastian Andrzej Siewior [this message]
2026-02-03 12:23                   ` Felix Maurer
2026-02-03 13:47                     ` Sebastian Andrzej Siewior
2026-02-03 15:07                       ` Felix Maurer
2026-01-22 14:56 ` [PATCH net-next v2 2/9] selftests: hsr: Check duplicates on HSR with VLAN Felix Maurer
2026-01-22 14:56 ` [PATCH net-next v2 3/9] selftests: hsr: Add tests for faulty links Felix Maurer
2026-01-22 14:56 ` [PATCH net-next v2 4/9] hsr: Implement more robust duplicate discard for PRP Felix Maurer
2026-01-28 16:38   ` Simon Horman
2026-01-28 18:37     ` Felix Maurer
2026-02-02 16:57       ` Sebastian Andrzej Siewior
2026-02-03 10:23         ` Felix Maurer
2026-02-03 11:57           ` Sebastian Andrzej Siewior
2026-02-03 12:42             ` Felix Maurer
2026-02-03 13:49               ` Sebastian Andrzej Siewior
2026-02-03 15:11                 ` Felix Maurer
2026-01-29 13:29   ` Sebastian Andrzej Siewior
2026-01-29 15:30     ` Felix Maurer
2026-02-02  8:47   ` Steffen Lindner
2026-01-22 14:57 ` [PATCH net-next v2 5/9] selftests: hsr: Add tests for more link faults with PRP Felix Maurer
2026-01-29 13:32   ` Sebastian Andrzej Siewior
2026-02-02 11:30     ` Felix Maurer
2026-02-02 16:45       ` Sebastian Andrzej Siewior
2026-02-03 12:09         ` Felix Maurer
2026-02-03 14:49           ` Sebastian Andrzej Siewior
2026-02-03 15:32             ` Felix Maurer
2026-01-22 14:57 ` [PATCH net-next v2 6/9] hsr: Implement more robust duplicate discard for HSR Felix Maurer
2026-01-29 14:43   ` Sebastian Andrzej Siewior
2026-01-29 16:17     ` Felix Maurer
2026-01-29 18:01       ` Felix Maurer
2026-01-30 10:34         ` Felix Maurer
2026-02-02 17:53           ` Sebastian Andrzej Siewior
2026-02-03 11:49             ` Felix Maurer
2026-02-03 12:08               ` Sebastian Andrzej Siewior
2026-02-02 17:11       ` Sebastian Andrzej Siewior
2026-02-03 11:08         ` Felix Maurer
2026-02-03 12:09           ` Sebastian Andrzej Siewior
2026-01-22 14:57 ` [PATCH net-next v2 7/9] selftests: hsr: Add more link fault tests " Felix Maurer
2026-01-22 14:57 ` [PATCH net-next v2 8/9] hsr: Update PRP duplicate discard KUnit test for new algorithm Felix Maurer
2026-01-29 15:12   ` Sebastian Andrzej Siewior
2026-01-29 16:19     ` Felix Maurer
2026-01-22 14:57 ` [PATCH net-next v2 9/9] MAINTAINERS: Assign hsr selftests to HSR Felix Maurer
2026-01-22 17:24 ` [PATCH net-next v2 0/9] hsr: Implement more robust duplicate discard algorithm Sebastian Andrzej Siewior
2026-01-23  1:35 ` Jakub Kicinski
2026-01-26  9:28   ` Felix Maurer
2026-01-29 15:29     ` Sebastian Andrzej Siewior
2026-01-29 16:29       ` Felix Maurer

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=20260203115526._PRE3nvY@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=allison.henderson@oracle.com \
    --cc=antonio@openvpn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmaurer@redhat.com \
    --cc=horms@kernel.org \
    --cc=jkarrenpalo@gmail.com \
    --cc=kuba@kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=tglx@linutronix.de \
    /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