From: Vladimir Oltean <vladimir.oltean@nxp.com> To: netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>, "David S. Miller" <davem@davemloft.net> Cc: 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>, Tobias Waldekranz <tobias@waldekranz.com>, Roopa Prabhu <roopa@nvidia.com>, Nikolay Aleksandrov <nikolay@nvidia.com>, Stephen Hemminger <stephen@networkplumber.org>, bridge@lists.linux-foundation.org, DENG Qingfang <dqfext@gmail.com> Subject: [PATCH net-next 0/3] Fan out FDB entries pointing towards the bridge to all switchdev member ports Date: Mon, 19 Jul 2021 16:51:37 +0300 [thread overview] Message-ID: <20210719135140.278938-1-vladimir.oltean@nxp.com> (raw) The "DSA RX filtering" series has added some important support for interpreting addresses towards the bridge device as host addresses and installing them as FDB entries towards the CPU port, but it does not cover all circumstances and needs further work. To be precise, the mechanism introduced in that series only works as long as the ports are fairly static and no port joins or leaves the bridge once the configuration is done. If any port leaves, host FDB entries that were installed during runtime (for example the user changes the MAC address of the bridge device) will be prematurely deleted, resulting in a broken setup. I see this work as targeted for "net-next" because technically it was not supposed to work. Also, there are still corner cases and holes to be plugged. For example, today, FDB entries on foreign interfaces are not covered by br_fdb_replay(), which means that there are cases where some host addresses are either lost, or never deleted by DSA. That will be resolved once more work gets accepted, in particular the "Allow forwarding for the software bridge data path to be offloaded to capable devices" series, which moves the br_fdb_replay() call to the bridge core and therefore would be required to solve the problem in a generic way for every switchdev driver and not just for DSA. These patches also pave the way for a cleaner implementation for FDB entries pointing towards a LAG upper interface in DSA (that code needs only to be added, nothing changed), however this is not done here. Vladimir Oltean (3): net: switchdev: introduce helper for checking dynamically learned FDB entries net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE net: dsa: use switchdev_handle_fdb_{add,del}_to_device include/net/switchdev.h | 62 ++++++++++++ net/dsa/dsa_priv.h | 19 +++- net/dsa/slave.c | 199 +++++++++++++++++++------------------- net/switchdev/switchdev.c | 190 ++++++++++++++++++++++++++++++++++++ 4 files changed, 365 insertions(+), 105 deletions(-) -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <vladimir.oltean@nxp.com> To: netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>, "David S. Miller" <davem@davemloft.net> Cc: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Jiri Pirko <jiri@resnulli.us>, DENG Qingfang <dqfext@gmail.com>, bridge@lists.linux-foundation.org, Ido Schimmel <idosch@idosch.org>, Nikolay Aleksandrov <nikolay@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>, Vivien Didelot <vivien.didelot@gmail.com>, Tobias Waldekranz <tobias@waldekranz.com> Subject: [Bridge] [PATCH net-next 0/3] Fan out FDB entries pointing towards the bridge to all switchdev member ports Date: Mon, 19 Jul 2021 16:51:37 +0300 [thread overview] Message-ID: <20210719135140.278938-1-vladimir.oltean@nxp.com> (raw) The "DSA RX filtering" series has added some important support for interpreting addresses towards the bridge device as host addresses and installing them as FDB entries towards the CPU port, but it does not cover all circumstances and needs further work. To be precise, the mechanism introduced in that series only works as long as the ports are fairly static and no port joins or leaves the bridge once the configuration is done. If any port leaves, host FDB entries that were installed during runtime (for example the user changes the MAC address of the bridge device) will be prematurely deleted, resulting in a broken setup. I see this work as targeted for "net-next" because technically it was not supposed to work. Also, there are still corner cases and holes to be plugged. For example, today, FDB entries on foreign interfaces are not covered by br_fdb_replay(), which means that there are cases where some host addresses are either lost, or never deleted by DSA. That will be resolved once more work gets accepted, in particular the "Allow forwarding for the software bridge data path to be offloaded to capable devices" series, which moves the br_fdb_replay() call to the bridge core and therefore would be required to solve the problem in a generic way for every switchdev driver and not just for DSA. These patches also pave the way for a cleaner implementation for FDB entries pointing towards a LAG upper interface in DSA (that code needs only to be added, nothing changed), however this is not done here. Vladimir Oltean (3): net: switchdev: introduce helper for checking dynamically learned FDB entries net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE net: dsa: use switchdev_handle_fdb_{add,del}_to_device include/net/switchdev.h | 62 ++++++++++++ net/dsa/dsa_priv.h | 19 +++- net/dsa/slave.c | 199 +++++++++++++++++++------------------- net/switchdev/switchdev.c | 190 ++++++++++++++++++++++++++++++++++++ 4 files changed, 365 insertions(+), 105 deletions(-) -- 2.25.1
next reply other threads:[~2021-07-19 13:53 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-19 13:51 Vladimir Oltean [this message] 2021-07-19 13:51 ` [Bridge] [PATCH net-next 0/3] Fan out FDB entries pointing towards the bridge to all switchdev member ports Vladimir Oltean 2021-07-19 13:51 ` [PATCH net-next 1/3] net: switchdev: introduce helper for checking dynamically learned FDB entries Vladimir Oltean 2021-07-19 13:51 ` [Bridge] " Vladimir Oltean 2021-07-19 13:51 ` [PATCH net-next 2/3] net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE Vladimir Oltean 2021-07-19 13:51 ` [Bridge] [PATCH net-next 2/3] net: switchdev: introduce a fanout helper for SWITCHDEV_FDB_{ADD, DEL}_TO_DEVICE Vladimir Oltean 2021-07-19 13:51 ` [PATCH net-next 3/3] net: dsa: use switchdev_handle_fdb_{add,del}_to_device Vladimir Oltean 2021-07-19 13:51 ` [Bridge] [PATCH net-next 3/3] net: dsa: use switchdev_handle_fdb_{add, del}_to_device Vladimir Oltean 2021-07-20 14:10 ` [PATCH net-next 0/3] Fan out FDB entries pointing towards the bridge to all switchdev member ports patchwork-bot+netdevbpf 2021-07-20 14:10 ` [Bridge] " patchwork-bot+netdevbpf
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=20210719135140.278938-1-vladimir.oltean@nxp.com \ --to=vladimir.oltean@nxp.com \ --cc=andrew@lunn.ch \ --cc=bridge@lists.linux-foundation.org \ --cc=davem@davemloft.net \ --cc=dqfext@gmail.com \ --cc=f.fainelli@gmail.com \ --cc=idosch@idosch.org \ --cc=jiri@resnulli.us \ --cc=kuba@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nikolay@nvidia.com \ --cc=roopa@nvidia.com \ --cc=stephen@networkplumber.org \ --cc=tobias@waldekranz.com \ --cc=vivien.didelot@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.