From: Vladimir Oltean
Date: Tue, 29 Jun 2021 22:09:23 +0300
> On Tue, Jun 29, 2021 at 09:58:22PM +0300, Vladimir Oltean wrote:
>> On Tue, Jun 29, 2021 at 11:52:13AM -0700, David Miller wrote:
>> > From: Vladimir Oltean
>> > Date: Tue, 29 Jun 2021 17:06:43 +0300
>> >
>> > > Changes in v5:
>> >
On Tue, Jun 29, 2021 at 09:58:22PM +0300, Vladimir Oltean wrote:
> On Tue, Jun 29, 2021 at 11:52:13AM -0700, David Miller wrote:
> > From: Vladimir Oltean
> > Date: Tue, 29 Jun 2021 17:06:43 +0300
> >
> > > Changes in v5:
> > > - added READ_ONCE and WRITE_ONCE for fdb->dst
> > > - removed a
On Tue, Jun 29, 2021 at 11:52:13AM -0700, David Miller wrote:
> From: Vladimir Oltean
> Date: Tue, 29 Jun 2021 17:06:43 +0300
>
> > Changes in v5:
> > - added READ_ONCE and WRITE_ONCE for fdb->dst
> > - removed a paranoid WARN_ON in DSA
> > - added some documentation regarding how 'bridge fdb'
From: Vladimir Oltean
Date: Tue, 29 Jun 2021 17:06:43 +0300
> Changes in v5:
> - added READ_ONCE and WRITE_ONCE for fdb->dst
> - removed a paranoid WARN_ON in DSA
> - added some documentation regarding how 'bridge fdb' is supposed to be
> used with DSA
Vlad, I applied v4, could you please
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Tue, 29 Jun 2021 17:06:43 +0300 you wrote:
> From: Vladimir Oltean
>
> This is my 5th stab at creating a list of unicast and multicast
> addresses that the DSA CPU ports must trap. I am reusing a lot of
> Tobias's
From: Vladimir Oltean
When
(a) "dev" is a bridge port which the DSA switch tree offloads, but is
otherwise not a dsa slave (such as a LAG netdev), or
(b) "dev" is the bridge net device itself
then strange things happen to the dev_hold/dev_put pair:
dsa_schedule_work() will still be called
From: Vladimir Oltean
When we join a bridge that already has some local addresses pointing to
itself, we do not get those notifications. Similarly, when we leave that
bridge, we do not get notifications for the deletion of those entries.
The only switchdev notifications we get are those of
From: Vladimir Oltean
The bridge supports a legacy way of adding local (non-forwarded) FDB
entries, which works on an individual port basis:
bridge fdb add dev swp0 00:01:02:03:04:05 master local
As well as a new way, added by Roopa Prabhu in commit 3741873b4f73
("bridge: allow adding of fdb
From: Vladimir Oltean
DSA is able to install FDB entries towards the CPU port for addresses
which were dynamically learnt by the software bridge on foreign
interfaces that are in the same bridge with a DSA switch interface.
Since this behavior is opportunistic, it is guarded by the
From: Tobias Waldekranz
The bridge automatically creates local (not forwarded) fdb entries
pointing towards physical ports with their interface MAC addresses.
For switchdev, the significance of these fdb entries is the exact
opposite of that of non-local entries: instead of sending these frame
From: Vladimir Oltean
If the DSA master implements strict address filtering, then the unicast
and multicast addresses kept by the DSA CPU ports should be synchronized
with the address lists of the DSA master.
Note that we want the synchronization of the master's address lists even
if the DSA
From: Vladimir Oltean
The same concerns expressed for host MDB entries are valid for host FDBs
just as well:
- in the case of multiple bridges spanning the same switch chip, deleting
a host FDB entry that belongs to one bridge will result in breakage to
the other bridge
- not deleting FDB
From: Vladimir Oltean
DSA treats some bridge FDB entries by trapping them to the CPU port.
Currently, the only class of such entries are FDB addresses learnt by
the software bridge on a foreign interface. However there are many more
to be added:
- FDB entries with the is_local flag (for
From: Vladimir Oltean
Ever since the cross-chip notifiers were introduced, the design was
meant to be simplistic and just get the job done without worrying too
much about dangling resources left behind.
For example, somebody installs an MDB entry on sw0p0 in this daisy chain
topology. It gets
From: Vladimir Oltean
Commit abd49535c380 ("net: dsa: execute dsa_switch_mdb_add only for
routing port in cross-chip topologies") does a surprisingly good job
even for the SWITCHDEV_OBJ_ID_HOST_MDB use case, where DSA simply
translates a switchdev object received on dp into a cross-chip notifier
From: Vladimir Oltean
When a port joins a bridge which already has local FDB entries pointing
to the bridge device itself, we would like to offload those, so allow
the "dev" argument to be equal to the bridge too. The code already does
what we need in that case.
Signed-off-by: Vladimir Oltean
From: Vladimir Oltean
In preparation for the new cross-chip notifiers for host addresses,
let's introduce some more topology helpers which we are going to use to
discern switches that are in our path towards the dedicated CPU port
from switches that aren't.
Signed-off-by: Vladimir Oltean
---
From: Tobias Waldekranz
Treat addresses added to the bridge itself in the same way as regular
ports and send out a notification so that drivers may sync it down to
the hardware FDB.
Signed-off-by: Tobias Waldekranz
Signed-off-by: Vladimir Oltean
---
v4->v5: rebased on top of the READ_ONCE
From: Vladimir Oltean
Annotate the writer side of fdb->dst:
- fdb_create()
- br_fdb_update()
- fdb_add_entry()
- br_fdb_external_learn_add()
with WRITE_ONCE() and the reader side:
- br_fdb_test_addr()
- br_fdb_update()
- fdb_fill_info()
- fdb_add_entry()
- fdb_delete_by_addr_and_port()
-
From: Vladimir Oltean
This is my 5th stab at creating a list of unicast and multicast
addresses that the DSA CPU ports must trap. I am reusing a lot of
Tobias's work which he submitted here:
https://patchwork.kernel.org/project/netdevbpf/cover/20210116012515.3152-1-tob...@waldekranz.com/
My
20 matches
Mail list logo
