From: Vladimir Oltean <olteanv@gmail.com>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>,
DENG Qingfang <dqfext@gmail.com>,
George McCollister <george.mccollister@gmail.com>,
Vlad Yasevich <vyasevich@gmail.com>,
Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <nikolay@nvidia.com>
Subject: Re: [RFC PATCH v2 net-next 15/17] net: dsa: replay port and local fdb entries when joining the bridge
Date: Fri, 26 Feb 2021 20:08:09 +0200 [thread overview]
Message-ID: <20210226180809.25xsn26gphxlvwv4@skbuf> (raw)
In-Reply-To: <87mtvrqapw.fsf@waldekranz.com>
On Fri, Feb 26, 2021 at 01:23:23PM +0100, Tobias Waldekranz wrote:
> If VLAN filtering is enabled, we would also have to replay that. Port
> attributes also, right?
>
> I like the pull model, because it saves the bridge from doing lots of
> dumpster diving. However, should there be a single `bridge_replay` that
> takes care of everything?
>
> Rather than this kit-car approarch which outsources ordering etc to each
> switchdev driver, you issue a single call saying: "bring me up to
> speed". It seems right that that knowledge should reside in the bridge
> since it was the one who sent the original events that are being
> replayed.
Yes, in the non-RFC version I'm going to do that.
I'm also thinking I could just pass the blocking and atomic switchdev
notifiers as an argument to the switchdev_bridge_port_offload_notify()
call, such that the drivers need to do one thing and one thing only.
For the purposes of this RFC I just wanted to have something that works
for address filtering.
next prev parent reply other threads:[~2021-02-26 18:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 11:43 [RFC PATCH v2 net-next 00/17] RX filtering in DSA Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 01/17] net: dsa: reference count the host mdb addresses Vladimir Oltean
2021-02-26 9:20 ` Tobias Waldekranz
2021-02-24 11:43 ` [RFC PATCH v2 net-next 02/17] net: dsa: reference count the host fdb addresses Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 03/17] net: dsa: install the host MDB and FDB entries in the master's RX filter Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 04/17] net: dsa: install the port MAC addresses as host fdb entries Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 05/17] net: bridge: implement unicast filtering for the bridge device Vladimir Oltean
2021-03-01 15:22 ` Ido Schimmel
2022-02-22 11:21 ` Vladimir Oltean
2022-02-22 16:54 ` Ido Schimmel
2022-02-22 17:18 ` Vladimir Oltean
2022-02-24 13:22 ` Ido Schimmel
2022-02-24 13:52 ` Vladimir Oltean
2022-03-01 16:20 ` Ido Schimmel
2022-03-02 11:17 ` Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 06/17] net: dsa: add addresses obtained from RX filtering to host addresses Vladimir Oltean
2021-02-26 10:59 ` Tobias Waldekranz
2021-02-26 13:28 ` Vladimir Oltean
2021-02-26 22:44 ` Tobias Waldekranz
2021-02-24 11:43 ` [RFC PATCH v2 net-next 07/17] net: bridge: switchdev: refactor br_switchdev_fdb_notify Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 08/17] net: bridge: switchdev: include local flag in FDB notifications Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 09/17] net: bridge: switchdev: send FDB notifications for host addresses Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 10/17] net: dsa: include bridge addresses which are local in the host fdb list Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 11/17] net: dsa: include fdb entries pointing to bridge " Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 12/17] net: dsa: sync static FDB entries on foreign interfaces to hardware Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 13/17] net: dsa: mv88e6xxx: Request assisted learning on CPU port Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 14/17] net: dsa: replay port and host-joined mdb entries when joining the bridge Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 15/17] net: dsa: replay port and local fdb " Vladimir Oltean
2021-02-26 12:23 ` Tobias Waldekranz
2021-02-26 18:08 ` Vladimir Oltean [this message]
2021-02-24 11:43 ` [RFC PATCH v2 net-next 16/17] net: bridge: switchdev: let drivers inform which bridge ports are offloaded Vladimir Oltean
2021-02-24 11:43 ` [RFC PATCH v2 net-next 17/17] net: bridge: offloaded ports are always promiscuous Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210226180809.25xsn26gphxlvwv4@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=dqfext@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=george.mccollister@gmail.com \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
--cc=roopa@nvidia.com \
--cc=tobias@waldekranz.com \
--cc=vivien.didelot@gmail.com \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox