On Thu Nov 19, 2020 at 1:51 PM CET, Vladimir Oltean wrote:

I have tested these patches on ocelot/felix and all is OK there, I would
appreciate if you could resend as non-RFC. In the case of my hardware,

For sure, I am working on it as we speak. I was mostly waiting for the
dsa-tag-unification series to make its way to net-next first as v1
depends on that. But then I remembered that I had to test against the
bonding driver (I have used team up to this point), and there is some
bug there that I need to squash first.

it appears that I don't need the .port_lag_change callback, and that the

Ok, does ocelot automatically rebalance the LAG based on link state? I
took a quick look through the datasheet for another switch from
Vitesse, and it explicitly states that you need to update a table on
link changes.

I.e. in this situation:

    br0
   /  |
 lag  |
 /|\  |
1 2 3 4
| | |  \
| | |   B
| | |
1 2 3
  A

If you unplug cable 1, does the hardware rebalance all flows between
A<->B to only use 2 and 3 without software assistance? If not, you
will loose 1/3 of your flows.

source port that is being put in the DSA header is still the physical
port ID and not the logical port ID (the LAG number). That being said,

Ok, yeah I really wish this was true for mv88e6xxx as well.

the framework you've built is clearly nice and works well even with
bridging a bond.

Thank you!