search for: dsa_fdb_flag_dynamic

...dp) > return 0; > @@ -3410,6 +3415,9 @@ static int dsa_slave_fdb_event(struct net_device *dev, > orig_dev->name, fdb_info->addr, fdb_info->vid, > host_addr ? " as host address" : ""); > > + if (fdb_info->is_dyn) > + fdb_flags |= DSA_FDB_FLAG_DYNAMIC; > + Hmm, I don't think this is going to work with the assisted_learning_on_cpu_port feature ("if (switchdev_fdb_is_dynamically_learned(fdb_info))"). The reason being that a "dynamically learned" FDB entry (defined as this): static inline bool switchdev_fdb_is_dynamical...

...ime, it would be along the lines > > of the following (completely untested!). I feel that it robustly covers > > all cases for fdb_flags. And as a bonus doesn't need to be modified > > if other (unsupported) flags are added in future. > > > > if (fdb_flags & ~(DSA_FDB_FLAG_DYNAMIC)) > > return -EOPNOTSUPP; > > > > is_dynamic = !!(fdb_flags & DSA_FDB_FLAG_DYNAMIC) > > if (is_dynamic) > > state = MV88E6XXX_G1_ATU_DATA_STATE_UC_AGE_7_NEWEST; > > > > > > And perhaps for other drivers: > > > > if (fdb_flags &a...

...-3410,6 +3415,9 @@ static int dsa_slave_fdb_event(struct net_device >> *dev, >> orig_dev->name, fdb_info->addr, fdb_info->vid, >> host_addr ? " as host address" : ""); >> >> + if (fdb_info->is_dyn) >> + fdb_flags |= DSA_FDB_FLAG_DYNAMIC; >> + > > Hmm, I don't think this is going to work with the > assisted_learning_on_cpu_port > feature ("if (switchdev_fdb_is_dynamically_learned(fdb_info))"). The > reason being > that a "dynamically learned" FDB entry (defined as this): > >...

On Thu, Mar 30, 2023 at 18:07, Vladimir Oltean <olteanv at gmail.com> wrote: > > Then, make DSA decide whether to handle the "added_by_user && !is_static" > combination or not, based on the presence of the DSA_FDB_FLAG_DYNAMIC > flag, which will be set in ds->supported_fdb_flags only for the mv88e6xxx > driver. Okay, so this will require a new function in the DSA layer that sets which flags are supported and that the driver will call on initialization. Where (in the DSA layer) should such a function be placed...

...TO_DEVICE handler appears) ignore the "added_by_user && !is_static" combination, but by their own choice and not by switchdev's choice. Then, make DSA decide whether to handle the "added_by_user && !is_static" combination or not, based on the presence of the DSA_FDB_FLAG_DYNAMIC flag, which will be set in ds->supported_fdb_flags only for the mv88e6xxx driver. When DSA_FDB_FLAG_DYNAMIC is not supported, DSA will not offload the FDB entry: neither will it call port_fdb_add(), nor will it emit SWITCHDEV_FDB_OFFLOADED. Ideally, it would also inform user space that it can...

On Thu, Mar 30, 2023 at 16:09, Vladimir Oltean <olteanv at gmail.com> wrote: > On Thu, Mar 30, 2023 at 02:59:04PM +0200, Hans Schultz wrote: >> On Thu, Mar 30, 2023 at 15:43, Vladimir Oltean <olteanv at gmail.com> wrote: >> > On Tue, Mar 28, 2023 at 09:45:26PM +0200, Hans Schultz wrote: >> >> So the solution would be to not let the DSA layer send the

...; > ds->configure_vlan_while_not_filtering = true; > > + /* Since dynamic FDB entries are legacy, all switch drivers should > + * support the flag at least by just installing a static entry and > + * letting the bridge age it. > + */ > + ds->supported_fdb_flags = DSA_FDB_FLAG_DYNAMIC; I believe that switchdev has a structural problem in the fact that FDB entries with flags that aren't interpreted by drivers (so they don't know if those flags are set or unset) are still passed to the switchdev notifier chains by default. I don't believe that anybody used 'bridg...