Thread (11 messages) 11 messages, 5 authors, 2021-01-19

Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports)

From: Vladimir Oltean <olteanv@gmail.com>
Date: 2021-01-18 21:21:15

On Sat, Jan 16, 2021 at 02:42:12AM +0100, Tobias Waldekranz wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help