[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210628220011.1910096-1-olteanv@gmail.com>
Date: Tue, 29 Jun 2021 00:59:57 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: netdev@...r.kernel.org
Cc: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
Ido Schimmel <idosch@...sch.org>,
Tobias Waldekranz <tobias@...dekranz.com>,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <nikolay@...dia.com>,
Vladimir Oltean <vladimir.oltean@....com>
Subject: [PATCH v4 net-next 00/14] RX filtering in DSA
From: Vladimir Oltean <vladimir.oltean@....com>
This is my fourth stab (identical to the third one except sent as
non-RFC) 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-tobias@waldekranz.com/
My additions to Tobias' work come in the form of taking some care that
additions and removals of host addresses are properly balanced, so that
we can do reference counting on them for cross-chip setups and multiple
bridges spanning the same switch (I am working on an NXP board where
both are real requirements).
During the last attempted submission of multiple CPU ports for DSA:
https://patchwork.kernel.org/project/netdevbpf/cover/20210410133454.4768-1-ansuelsmth@gmail.com/
it became clear that the concept of multiple CPU ports would not be
compatible with the idea of address learning on those CPU ports (when
those CPU ports are statically assigned to user ports, not in a LAG)
unless the switch supports complete FDB isolation, which most switches
do not. So DSA needs to manage in software all addresses that are
installed on the CPU port(s), which is what this patch set does.
Compared to all earlier attempts, this series does not fiddle with how
DSA operates the ports in standalone mode at all, just when bridged.
We need to sort that out properly, then any optimization that comes in
standalone mode (i.e. IFF_UNICAST_FLT) can come later.
Tobias Waldekranz (3):
net: bridge: switchdev: send FDB notifications for host addresses
net: dsa: sync static FDB entries on foreign interfaces to hardware
net: dsa: include bridge addresses which are local in the host fdb
list
Vladimir Oltean (11):
net: bridge: allow br_fdb_replay to be called for the bridge device
net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del
net: dsa: introduce dsa_is_upstream_port and dsa_switch_is_upstream_of
net: dsa: introduce a separate cross-chip notifier type for host MDBs
net: dsa: reference count the MDB entries at the cross-chip notifier
level
net: dsa: introduce a separate cross-chip notifier type for host FDBs
net: dsa: reference count the FDB addresses at the cross-chip notifier
level
net: dsa: install the host MDB and FDB entries in the master's RX
filter
net: dsa: include fdb entries pointing to bridge in the host fdb list
net: dsa: ensure during dsa_fdb_offload_notify that dev_hold and
dev_put are on the same dev
net: dsa: replay the local bridge FDB entries pointing to the bridge
dev too
include/net/dsa.h | 39 ++++++
net/bridge/br_fdb.c | 7 +-
net/bridge/br_private.h | 7 +-
net/bridge/br_switchdev.c | 11 +-
net/dsa/dsa2.c | 14 ++
net/dsa/dsa_priv.h | 14 ++
net/dsa/port.c | 86 ++++++++++++
net/dsa/slave.c | 102 +++++++-------
net/dsa/switch.c | 276 +++++++++++++++++++++++++++++++++++++-
9 files changed, 488 insertions(+), 68 deletions(-)
--
2.25.1
Powered by blists - more mailing lists