All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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: link
Be 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.