search for: switchdev_fdb_offloaded

...n > 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 with a single notifier emitted from the driver side,...

...fdb replace ... dynamic'. > > Why not? I find it reasonable that the software bridge does not age out > a dynamic FDB entry that is offloaded to hardware... the hardware should > do that ("dynamic" being the key). 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 i...

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 > SWITCHDEV_FDB_OFFLOADED event in the case when the new dynamic flag is > set? I have never said that.

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 >> SWITCHDEV_FDB_OFFLOADED event in the case when the new dynamic flag is >> set? > > I have never said that. No, I was just thinking of a solution based on your previous comment that dynamic fdb entries with the offloaded flag set should not be aged out by the bridge as they are now.

...ar 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 > >> SWITCHDEV_FDB_OFFLOADED event in the case when the new dynamic flag is > >> set? > > > > I have never said that. > > No, I was just thinking of a solution based on your previous comment > that dynamic fdb entries with the offloaded flag set should not be aged > out by the bridge as they a...

...2: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 >> >> SWITCHDEV_FDB_OFFLOADED event in the case when the new dynamic flag is >> >> set? >> > >> > I have never said that. >> >> No, I was just thinking of a solution based on your previous comment >> that dynamic fdb entries with the offloaded flag set should not be aged >>...

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

...tries 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 adds the offloaded flag in dsa_slave_switchdev_event_work() in slave.c. 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. I have at some point earlier asked why there would be two quite equivalent flags and what the difference between them are, but I didn't get a response. Now I see the difference and that I cannot use the...

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: https://lore.kernel.org/netdev/20230130173429.3577450-6-netdev at kapio-technology.com/ or the RFC: https://lore.ke...

...atic" 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 propagation mechanism from switchdev to the bridge FDB is a known limitation which is hard to overcome, and is outside the scope of your patchset I believe. To see whether D...

On Mon, Mar 27, 2023 at 05:31:26PM +0200, Hans Schultz wrote: > 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 >