search for: mv88e6xxx

...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 & ~(DSA_FDB_FLAG_DYNAMIC)) > > return -EOPNOTSUPP; > > if (fdb_flags) > > return 0; > > > > Perhaps a helper would be warranted f...

...at gmail.com> wrote: > > which idea is that, again? So I cannot us the offloaded flag as it is added by DSA in the common case when using 'bridge fdb replace ... dynamic'. The idea is then to use the ext_learn flag instead, which is not aged by the bridge. To do this the driver (mv88e6xxx) will send a SWITCHDEV_FDB_ADD_TO_BRIDGE switchdev event when the new dynamic flag is true. The function sending this event will then be named mv88e6xxx_add_fdb_synth_learned() in drivers/net/dsa/mv88e6xxx/switchdev.c, replacing the mv88e6xxx_set_fdb_offloaded() function but in most part the same c...

...> affects Felix Ocelot. Thus I am quite sure the results will be the same > without this patchset, ergo it must be because of another patch. All > that is done here in the DSA layer is to pass on an extra field and add > an extra check that will always pass in the case of this flag. If mv88e6xxx is all you have, you can still sanity-check the equivalent effect of your patch set to other drivers by simply not acting upon the "flags" argument in mv88e6xxx_port_fdb_add()/mv88e6xxx_port_fdb_del(), and disabling the logic to treat Age Out interrupts. Then you should be able to notice...

..."bool pls_dont_age_out", and I would make dsa_fdb_offload_notify() set this to true if the driver did actually install the dynamic FDB entry as dynamic in the ATU. > > The idea is then to use the ext_learn flag instead, which is not aged by > the bridge. To do this the driver (mv88e6xxx) will send a > SWITCHDEV_FDB_ADD_TO_BRIDGE switchdev event when the new dynamic flag is > true. The function sending this event will then be named > mv88e6xxx_add_fdb_synth_learned() in > drivers/net/dsa/mv88e6xxx/switchdev.c, replacing the > mv88e6xxx_set_fdb_offloaded() function bu...

...o *fdb_info) > { > return !fdb_info->added_by_user && !fdb_info->is_local; > } > > is also dynamic in the DSA_FDB_FLAG_DYNAMIC sense. But we install a > static FDB entry for it on the CPU port. > > And in your follow-up patch 3/5, you make all drivers except mv88e6xxx > ignore all DSA_FDB_FLAG_DYNAMIC entries (including the ones snooped > from > address learning on software interfaces). So this breaks those drivers > which don't implement DSA_FDB_FLAG_DYNAMIC but do set > ds->assisted_learning_on_cpu_port > to true. I am not sure I und...

...(const struct switchdev_notifier_fdb_info *fdb_info) { return !fdb_info->added_by_user && !fdb_info->is_local; } is also dynamic in the DSA_FDB_FLAG_DYNAMIC sense. But we install a static FDB entry for it on the CPU port. And in your follow-up patch 3/5, you make all drivers except mv88e6xxx ignore all DSA_FDB_FLAG_DYNAMIC entries (including the ones snooped from address learning on software interfaces). So this breaks those drivers which don't implement DSA_FDB_FLAG_DYNAMIC but do set ds->assisted_learning_on_cpu_port to true. I think you also want to look at the added_by_user...

On Mon, Mar 27, 2023 at 14:52, Vladimir Oltean <olteanv at gmail.com> wrote: > > By the way, there is a behavior change here. > > Before: > > $ ip link add br0 type bridge && ip link set br0 up > $ ip link set swp0 master br0 && ip link set swp0 up > $ bridge fdb add dev swp0 00:01:02:03:04:05 master dynamic > [ 70.010181] mscc_felix 0000:00:00.5:

On Mon, Mar 27, 2023 at 11:49:58PM +0200, Hans Schultz wrote: > My first approach was to use the SWITCHDEV_FDB_ADD_TO_BRIDGE event > and not the SWITCHDEV_FDB_OFFLOADED event as the first would set the > external learned flag which is not aged out by the bridge. Link to patch? I don't see any SWITCHDEV_FDB_ADD_TO_BRIDGE call in either the v1:

...ladimir 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 and what should it be called?

...mbination, 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't offload this flag by returning an error, but the lack of an error propaga...

...2023 at 19:00, Vladimir Oltean <olteanv at gmail.com> wrote: > A reasonable question you could ask yourself is: why do my BR_FDB_OFFLOADED > entries have this flag in the software bridge in the first place? > Did I add code for it? Is it because there is some difference between > mv88e6xxx and ocelot/felix, or is it because dsa_fdb_offload_notify() > gets called in both cases from generic code just the same? > > And if dsa_fdb_offload_notify() gets called in both cases just the same, > but no other driver except for mv88e6xxx emits the SWITCHDEV_FDB_DEL_TO_BRIDGE > whi...

.... So the solution would be to not let the DSA layer send the SWITCHDEV_FDB_OFFLOADED event in the case when the new dynamic flag is set? Thus other drivers that don't support the flag yet will install a static entry in HW and the bridge will age it out as there is no offloaded flag on. For the mv88e6xxx it will set the offloaded flag and HW will age it. > At least, I find it more reasonable > than the current behavior, where the bridge notifies dynamic FDB entries > to switchdev, but doesn't say they're dynamic, and switchdev treats them > as static, so they don't roam fro...

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

...+- drivers/net/dsa/b53/b53_common.c | 2 +- drivers/net/dsa/b53/b53_serdes.c | 2 +- drivers/net/dsa/bcm_sf2.c | 2 +- drivers/net/dsa/microchip/ksz9477.c | 2 +- drivers/net/dsa/mt7530.c | 2 +- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/ethernet/3com/3c509.c | 4 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 2 +- drivers/net/ethernet/8390/pcnet_cs.c | 2 +- drivers/net/ethernet/alacritech/slicoss.c...

...+- drivers/net/dsa/b53/b53_common.c | 2 +- drivers/net/dsa/b53/b53_serdes.c | 2 +- drivers/net/dsa/bcm_sf2.c | 2 +- drivers/net/dsa/microchip/ksz9477.c | 2 +- drivers/net/dsa/mt7530.c | 2 +- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/ethernet/3com/3c509.c | 4 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 2 +- drivers/net/ethernet/8390/pcnet_cs.c | 2 +- drivers/net/ethernet/alacritech/slicoss.c...

...+- drivers/net/dsa/b53/b53_common.c | 2 +- drivers/net/dsa/b53/b53_serdes.c | 2 +- drivers/net/dsa/bcm_sf2.c | 2 +- drivers/net/dsa/microchip/ksz9477.c | 2 +- drivers/net/dsa/mt7530.c | 2 +- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/ethernet/3com/3c509.c | 4 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 2 +- drivers/net/ethernet/8390/pcnet_cs.c | 2 +- drivers/net/ethernet/alacritech/slicoss.c...

...+- drivers/net/dsa/b53/b53_common.c | 2 +- drivers/net/dsa/b53/b53_serdes.c | 2 +- drivers/net/dsa/bcm_sf2.c | 2 +- drivers/net/dsa/microchip/ksz9477.c | 2 +- drivers/net/dsa/mt7530.c | 2 +- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/ethernet/3com/3c509.c | 4 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 2 +- drivers/net/ethernet/8390/pcnet_cs.c | 2 +- drivers/net/ethernet/alacritech/slicoss.c...

...+- drivers/net/dsa/b53/b53_common.c | 2 +- drivers/net/dsa/b53/b53_serdes.c | 2 +- drivers/net/dsa/bcm_sf2.c | 2 +- drivers/net/dsa/microchip/ksz9477.c | 2 +- drivers/net/dsa/mt7530.c | 2 +- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/ethernet/3com/3c509.c | 4 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 2 +- drivers/net/ethernet/8390/pcnet_cs.c | 2 +- drivers/net/ethernet/alacritech/slicoss.c...