search for: switchdev_fdb_add_to_device

Displaying 8 results from an estimated 8 matches for "switchdev_fdb_add_to_device".

2023 Apr 12
1
[Bridge] [PATCH net] net: bridge: switchdev: don't notify FDB entries with "master dynamic"
...f 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?
2023 Apr 12
1
[Bridge] [PATCH net] net: bridge: switchdev: don't notify FDB entries with "master dynamic"
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 can roam in which case it becomes age-able. TBH, I think most de...
2023 Apr 12
1
[Bridge] [PATCH net] net: bridge: switchdev: don't notify FDB entries with "master dynamic"
On Wed, Apr 12, 2023 at 07:00:02PM +0300, Ido Schimmel wrote: > 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 can roam in which case it becomes age-ab...
2023 Mar 30
2
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
...tchdev those FDB entries with BR_FDB_ADDED_BY_USER && !BR_FDB_STATIC. Then, after "net" is merged into "net-next" next Thursday (the ship has sailed for today), add "bool static" to the switchdev notifier info, and make all switchdev drivers (everywhere where a SWITCHDEV_FDB_ADD_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_F...
2023 Mar 30
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
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
2023 Mar 28
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
On Tue, Mar 28, 2023 at 01:59, Vladimir Oltean <olteanv 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
2023 Mar 28
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
...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 > content, just another event type. Basically you're suggesting that the hardware driver, after receiving a SWITCHDEV_FDB_ADD_TO_DEVICE and responding to it with SWITCHDEV_FDB_OFFLOADED, emits a SWITCHDEV_FDB_ADD_TO_BRIDGE which takes over that software bridge FDB entry, with the advantage that the new one already has the semantics of not being aged out by the software bridge. hmmm... I'd say that the flow should work even wit...
2023 Apr 12
1
[Bridge] [PATCH net] net: bridge: switchdev: don't notify FDB entries with "master dynamic"
On Mon, Apr 10, 2023 at 11:49:51PM +0300, Vladimir Oltean wrote: > 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