On Tue, Feb 9, 2021 at 11:20 AM Vladimir Oltean <olte...@gmail.com> wrote: > > 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.
Do I just return -EOPNOTSUPP instead of 0 in dsa_switch_hsr_join and dsa_switch_hsr_leave? I'm not sure exactly what you're saying needs to be done wrt to address learning with HSR. The switch does address learning internally. Are you saying the DSA address learning needs to be disabled? If that's something I need for this patch some tips on what to do would be appreciated because I'm a bit lost. Thanks
