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!
