Displaying 3 results from an estimated 3 matches for "switchdev_fdb_del_to_bridg".
Did you mean:
switchdev_fdb_del_to_bridge
2023 Mar 27
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
...ge FDB will get the BR_FDB_OFFLOADED
~~~~~~~~~~~~~~~~~~~~
flag set, we do not want the bridge to age those entries and we want the
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
entries to be deleted in the bridge upon an SWITCHDEV_FDB_DEL_TO_BRIDGE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
existing drivers do not emit this
event.
Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com>
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index...
2023 Mar 27
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
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:
2023 Mar 27
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
...me 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
> which you've patched the bridge to expect in this series, then what exactly
> is surprising in the fact that offloaded and dynamic FDB entries now become
> stale, but are not removed from the software bridge as they were before?
Yes, I see I have missed that the dsa layer already a...