Re: [PATCH net-next v2 3/4] net: dsa: add support for offloading HSR

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Feb 08, 2021 at 11:21:26AM -0600, George McCollister wrote:
> > If you return zero, the software fallback is never going to kick in.
>
> For join and leave? How is this not a problem for the bridge and lag
> functions? They work the same way don't they? I figured it would be
> safe to follow what they were doing.

I didn't say that the bridge and LAG offloading logic does the right
thing, but it is on its way there...

Those "XXX not offloaded" messages were tested with cases where the
.port_lag_join callback _is_ present, but fails (due to things like
incompatible xmit hashing policy). They were not tested with the case
where the driver does not implement .port_lag_join at all.

Doesn't mean you shouldn't do the right thing. I'll send some patches
soon, hopefully, fixing that for LAG and the bridge, you can concentrate
on HSR. For the non-offload scenario where the port is basically
standalone, we also need to disable the other bridge functions such as
address learning, otherwise it won't work properly, and that's where
I've been focusing my attention lately. You can't offload the bridge in
software, or a LAG, if you have address learning enabled. For HSR it's
even more interesting, you need to have address learning disabled even
when you offload the DANH/DANP.