mbox series

[v4,resend,net-next,0/4] Cross-chip bridging for disjoint DSA trees

Message ID 20200510163743.18032-1-olteanv@gmail.com
Headers show
Series Cross-chip bridging for disjoint DSA trees | expand

Message

Vladimir Oltean May 10, 2020, 4:37 p.m. UTC
From: Vladimir Oltean <vladimir.oltean@nxp.com>

This series adds support for boards where DSA switches of multiple types
are cascaded together. Actually this type of setup was brought up before
on netdev, and it looks like utilizing disjoint trees is the way to go:

https://lkml.org/lkml/2019/7/7/225

The trouble with disjoint trees (prior to this patch series) is that only
bridging of ports within the same hardware switch can be offloaded.
After scratching my head for a while, it looks like the easiest way to
support hardware bridging between different DSA trees is to bridge their
DSA masters and extend the crosschip bridging operations.

I have given some thought to bridging the DSA masters with the slaves
themselves, but given the hardware topology described in the commit
message of patch 4/4, virtually any number (and combination) of bridges
(forwarding domains) can be created on top of those 3x4-port front-panel
switches. So it becomes a lot less obvious, when the front-panel ports
are enslaved to more than 1 bridge, which bridge should the DSA masters
be enslaved to.

So the least awkward approach was to just create a completely separate
bridge for the DSA masters, whose entire purpose is to permit hardware
forwarding between the discrete switches beneath it.

This is a direct resend of v3, which was deferred due to lack of review.
In the meantime Florian has reviewed and tested some of them.

v1 was submitted here:
https://patchwork.ozlabs.org/project/netdev/cover/20200429161952.17769-1-olteanv@gmail.com/

v2 was submitted here:
https://patchwork.ozlabs.org/project/netdev/cover/20200430202542.11797-1-olteanv@gmail.com/

v3 was submitted here:
https://patchwork.ozlabs.org/project/netdev/cover/20200503221228.10928-1-olteanv@gmail.com/

Vladimir Oltean (4):
  net: bridge: allow enslaving some DSA master network devices
  net: dsa: permit cross-chip bridging between all trees in the system
  net: dsa: introduce a dsa_switch_find function
  net: dsa: sja1105: implement cross-chip bridging operations

 drivers/net/dsa/mv88e6xxx/chip.c       |  16 ++-
 drivers/net/dsa/sja1105/sja1105.h      |   2 +
 drivers/net/dsa/sja1105/sja1105_main.c |  90 +++++++++++++++
 include/linux/dsa/8021q.h              |  45 ++++++++
 include/net/dsa.h                      |  13 ++-
 net/bridge/br_if.c                     |  32 ++++--
 net/bridge/br_input.c                  |  23 +++-
 net/bridge/br_private.h                |   6 +-
 net/dsa/dsa2.c                         |  21 ++++
 net/dsa/dsa_priv.h                     |   1 +
 net/dsa/port.c                         |  23 +++-
 net/dsa/switch.c                       |  21 +++-
 net/dsa/tag_8021q.c                    | 151 +++++++++++++++++++++++++
 13 files changed, 414 insertions(+), 30 deletions(-)

Comments

Jakub Kicinski May 11, 2020, 2:56 a.m. UTC | #1
On Sun, 10 May 2020 19:37:39 +0300 Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> This series adds support for boards where DSA switches of multiple types
> are cascaded together. Actually this type of setup was brought up before
> on netdev, and it looks like utilizing disjoint trees is the way to go:
> 
> https://lkml.org/lkml/2019/7/7/225
> 
> The trouble with disjoint trees (prior to this patch series) is that only
> bridging of ports within the same hardware switch can be offloaded.
> After scratching my head for a while, it looks like the easiest way to
> support hardware bridging between different DSA trees is to bridge their
> DSA masters and extend the crosschip bridging operations.
> 
> I have given some thought to bridging the DSA masters with the slaves
> themselves, but given the hardware topology described in the commit
> message of patch 4/4, virtually any number (and combination) of bridges
> (forwarding domains) can be created on top of those 3x4-port front-panel
> switches. So it becomes a lot less obvious, when the front-panel ports
> are enslaved to more than 1 bridge, which bridge should the DSA masters
> be enslaved to.
> 
> So the least awkward approach was to just create a completely separate
> bridge for the DSA masters, whose entire purpose is to permit hardware
> forwarding between the discrete switches beneath it.
> 
> This is a direct resend of v3, which was deferred due to lack of review.
> In the meantime Florian has reviewed and tested some of them.
> 
> v1 was submitted here:
> https://patchwork.ozlabs.org/project/netdev/cover/20200429161952.17769-1-olteanv@gmail.com/
> 
> v2 was submitted here:
> https://patchwork.ozlabs.org/project/netdev/cover/20200430202542.11797-1-olteanv@gmail.com/
> 
> v3 was submitted here:
> https://patchwork.ozlabs.org/project/netdev/cover/20200503221228.10928-1-olteanv@gmail.com/

Applied, thanks everyone!