search for: br_fdb_added_by_ext_learn

On Wed, Apr 12, 2023 at 07:24:07PM +0300, Vladimir Oltean wrote: > I'll send v2 with BR_FDB_ADDED_BY_EXT_LEARN not prevented from being > notified from switchdev. > > Unless you have any objection, I won't send v2 like this: > > if (test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags) && > !test_bit(BR_FDB_STATIC, &fdb->flags) && > !test_bit(BR_FDB_...

...sure I'm not missing something (and surprise, I was). The comment regarding BR_FDB_STATIC vs BR_FDB_STATIC | BR_FDB_STICKY is interesting. This whole "hey, did you know you were never using the bridge fdb flags correctly?" is starting to become a bit of a meme. I'll send v2 with BR_FDB_ADDED_BY_EXT_LEARN not prevented from being notified from switchdev. Unless you have any objection, I won't send v2 like this: if (test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags) && !test_bit(BR_FDB_STATIC, &fdb->flags) && !test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->fl...

...644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -537,6 +537,7 @@ void br_fdb_cleanup(struct work_struct *work) unsigned long this_timer = f->updated + delay; if (test_bit(BR_FDB_STATIC, &f->flags) || + test_bit(BR_FDB_OFFLOADED, &f->flags) || test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &f->flags)) { if (test_bit(BR_FDB_NOTIFY, &f->flags)) { if (time_after(this_timer, now)) @@ -1465,7 +1466,9 @@ int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p, spin_lock_bh(&br->hash_lock); fdb = br_fdb_find(br, addr, vid); - if (f...

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 Wed, Apr 12, 2023 at 05:27:33PM +0300, Vladimir Oltean wrote: > How are extern_learn FDB entries processed by spectrum's > SWITCHDEV_FDB_ADD_TO_DEVICE handler? No different than "BR_FDB_STATIC", which is a bug I'm aware of and intend to fix in net-next when I get the time (together with all the other combinations enabled by the bridge). Entry has ageing disabled, but

...s/testing/selftests/net/forwarding/, there is no valid > use of the "bridge fdb add ... master dynamic" command there, so I am > fairly confident that no one used to rely on this behavior. Yes, but there are tests that use "extern_learn". If you post a v2 that takes "BR_FDB_ADDED_BY_EXT_LEARN" into account, then I can ask Petr to run it through our regression and report back (not sure we will make it to this week's PR though). Thanks > > With the change in place, these FDB entries are no longer offloaded: > > bridge fdb get 00:01:02:03:04:05 dev swp0 master >...

...orwarding/, there is no valid > > use of the "bridge fdb add ... master dynamic" command there, so I am > > fairly confident that no one used to rely on this behavior. > > Yes, but there are tests that use "extern_learn". If you post a v2 that > takes "BR_FDB_ADDED_BY_EXT_LEARN" into account, then I can ask Petr to > run it through our regression and report back (not sure we will make it > to this week's PR though). > > Thanks How are extern_learn FDB entries processed by spectrum's SWITCHDEV_FDB_ADD_TO_DEVICE handler?

There is a structural problem in switchdev, where the flag bits in struct switchdev_notifier_fdb_info (added_by_user, is_local etc) only represent a simplified / denatured view of what's in struct net_bridge_fdb_entry :: flags (BR_FDB_ADDED_BY_USER, BR_FDB_LOCAL etc). Each time we want to pass more information about struct net_bridge_fdb_entry :: flags to struct switchdev_notifier_fdb_info

...s on their bridge port, so allow the bridge creator to limit the number of entries. Currently the manual entries are identified by the bridge flags BR_FDB_LOCAL or BR_FDB_ADDED_BY_USER, and changes to those flags are protected under a lock. This means the limit also applies to entries created with BR_FDB_ADDED_BY_EXT_LEARN but none of the other two, e.g. ones added by SWITCHDEV_FDB_ADD_TO_BRIDGE. v1: https://lore.kernel.org/netdev/20230515085046.4457-1-jnixdorf-oss at avm.de/ Changes since v1: - Added BR_FDB_ADDED_BY_USER earlier in fdb_add_entry to ensure the limit is not applied. - Do not initialize fdb_*_en...