netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	Andrew Lunn <andrew@lunn.ch>,
	Network Development <netdev@vger.kernel.org>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>
Subject: Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports)
Date: Mon, 18 Jan 2021 23:19:24 +0200	[thread overview]
Message-ID: <20210118211924.u2bl6ynmo5kdyyff@skbuf> (raw)
In-Reply-To: <87h7nhlksr.fsf@waldekranz.com>

On Sat, Jan 16, 2021 at 02:42:12AM +0100, Tobias Waldekranz wrote:
> > What I'm _really_ trying to do is to get my mv88e6250 to participate in
> > an MRP ring, which AFAICT will require that the master device's MAC gets
> > added as a static entry in the ATU: Otherwise, when the ring goes from
> > open to closed, I've seen the switch wrongly learn the node's own mac
> > address as being in the direction of one of the normal ports, which
> > obviously breaks all traffic. So if the topology is
> >
> >    M
> >  /   \
> > C1 *** C2
> >
> > with the link between C1 and C2 being broken, both M-C1 and M-C2 links
> > are in forwarding (hence learning) state, so when the C1-C2 link gets
> > reestablished, it will take at least one received test packet for M to
> > decide to put one of the ports in blocking state - by which time the
> > damage is done, and the ATU now has a broken entry for M's own mac address.

What hardware offload features do you need to use for MRP on mv88e6xxx?
If none, then considering that Tobias's bridge series may stall, I think
by far the easiest approach would be for DSA to detect that it can't
offload the bridge+MRP configuration, and keep all ports as standalone.
When in standalone mode, the ports don't offload any bridge flags, i.e.
they don't do address learning, and the only forwarding destination
allowed is the CPU. The only disadvantage is that this is software-based
forwarding.

  parent reply	other threads:[~2021-01-18 21:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 13:49 commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports) Rasmus Villemoes
2021-01-16  1:42 ` Tobias Waldekranz
2021-01-18 15:41   ` Rasmus Villemoes
2021-01-18 17:50     ` Andrew Lunn
2021-01-18 18:30       ` Tobias Waldekranz
2021-01-18 19:01         ` Andrew Lunn
2021-01-18 19:10           ` Tobias Waldekranz
2021-01-18 21:19   ` Vladimir Oltean [this message]
2021-01-18 22:07     ` Rasmus Villemoes
2021-01-18 23:08       ` Tobias Waldekranz
2021-01-19  9:15       ` Horatiu Vultur

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=20210118211924.u2bl6ynmo5kdyyff@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=horatiu.vultur@microchip.com \
    --cc=netdev@vger.kernel.org \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@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;
as well as URLs for NNTP newsgroup(s).