All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Maurer <fmaurer@redhat.com>
To: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org
Cc: bigeasy@linutronix.de, fmancera@suse.de, liuhangbin@gmail.com,
	luka.gejak@linux.dev, xiaoliang.yang_1@nxp.com,
	kexinsun@smail.nju.edu.cn, ssrane_b23@ee.vjti.ac.in,
	michael.bommarito@gmail.com, 2022090917019@std.uestc.edu.cn,
	yury.norov@gmail.com, jvaclav@redhat.com, maoyixie.tju@gmail.com
Subject: [RFC net-next 0/2] hsr: Use only one MAC address per node
Date: Tue, 14 Jul 2026 12:52:41 +0200	[thread overview]
Message-ID: <cover.1784024900.git.fmaurer@redhat.com> (raw)

Many places in the hsr module assumed that a single node could be using
multiple MAC addresses to communicate in the network. The standard is
explicit that PRP nodes should use the same MAC for frames on both
ports and commit b65999e7238e ("net: hsr: sync hw addr of slave2
according to slave1 hw addr on PRP") made this clear. For HSR, the
standard is less explicit. But after quite some discussions and reading
standards, Fernando, Sebastian, and I concluded that it never mentions
different MAC addresses for HSR either and instead often suggests using
equal addresses for both ports and this should be what hsr interfaces
do.

A short history of how this assumption formed in the kernel supports
this as well: the original HSRv0 code implemented IEC 62439-3:2010 where
node tables had two MAC addresses per node. It was an optional feature
to support an unspecified address substitution mechanism for _PRP_, also
referred to as PICS_SUBS. Note that we never even supported PRPv0 from
the :2010 standard. In IEC 62439-3:2012, the feature was explicitly
removed. But with two addresses per node in the node table and selftests
setting different addresses for both interfaces, the assumption emerged
that all nodes can have two addresses. In :2010, this was optional and
the standard is written so that a node not supporting PICS_SUBS could
just ignore it. Since 2012:, nodes must use the same address for both
ports in the ring.

To prevent misconfiguration and simplify the hsr code, this patchset
removes the notion of two different MAC addresses for one node in the
network entirely. The first patch sets equal addresses on both ports so
that we are not running in invalid configurations. I also updates the
selftest to not use/expect different addresses on the two ports. The
second patch removes MAC address B from the node table and thereby
eliminates a lot of code, including the node merging.

I am posting as an RFC for now mostly for two reasons: First, I want to
make sure it's generally accepted to have only a single MAC address per
node and give everyone the chance to speak up against this.

Second, I adapted the PRP address handling to HSR as well, i.e., to copy
the address from port A to port B and master, mostly because it is low
effort. I am not sure though if this is the best approach now that we
touch this part of the code anyways. I have two alternative ideas how
addresses should be handled:

1) Make the master control the port MAC addresses: when the hsr
   interface is created, generate a MAC address and assign it to both
   ports. Changing the address afterwards would also only go through the
   hsr interface which would update both ports.
2) Don't change the MAC addresses of the port interfaces at all. Instead
   behave similar to bridge where the ports keep their addresses and
   traffic from the bridge/master gets its own MAC address assigned.

What do you think? Do you prefer any of these approaches?

Thanks,
   Felix


Cc: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Felix Maurer (2):
  hsr: Set equal MAC addresses on port A and B for HSR
  hsr: Remove second MAC address from node table

 net/hsr/hsr_debugfs.c                         |   9 +-
 net/hsr/hsr_device.c                          |  23 +-
 net/hsr/hsr_forward.c                         |   8 +-
 net/hsr/hsr_framereg.c                        | 250 ++----------------
 net/hsr/hsr_framereg.h                        |  14 +-
 net/hsr/hsr_main.c                            |  18 +-
 net/hsr/hsr_main.h                            |   5 +-
 net/hsr/hsr_netlink.c                         |  18 +-
 tools/testing/selftests/net/hsr/hsr_ping.sh   |  33 +--
 tools/testing/selftests/net/hsr/hsr_redbox.sh |  13 +-
 .../testing/selftests/net/hsr/link_faults.sh  |  26 --
 11 files changed, 62 insertions(+), 355 deletions(-)


base-commit: f6f3b36c15ed44de1fbb44e645e4fae8c4a4453e
--
2.55.0


             reply	other threads:[~2026-07-14 10:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 10:52 Felix Maurer [this message]
2026-07-14 10:52 ` [RFC net-next 1/2] hsr: Set equal MAC addresses on port A and B for HSR Felix Maurer
2026-07-14 10:52 ` [RFC net-next 2/2] hsr: Remove second MAC address from node table 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=cover.1784024900.git.fmaurer@redhat.com \
    --to=fmaurer@redhat.com \
    --cc=2022090917019@std.uestc.edu.cn \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=jvaclav@redhat.com \
    --cc=kexinsun@smail.nju.edu.cn \
    --cc=kuba@kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=luka.gejak@linux.dev \
    --cc=maoyixie.tju@gmail.com \
    --cc=michael.bommarito@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ssrane_b23@ee.vjti.ac.in \
    --cc=xiaoliang.yang_1@nxp.com \
    --cc=yury.norov@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 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.