| Message ID | 20200503221228.10928-1-olteanv@gmail.com |
|---|---|
| Headers | show |
| Series | Cross-chip bridging for disjoint DSA trees | expand |
Hi David, On Mon, 4 May 2020 at 01:12, Vladimir Oltean <olteanv@gmail.com> 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. > > 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/ > > 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(-) > > -- > 2.17.1 > What does it mean that this series is "deferred" in patchwork? Thanks, -Vladimir
From: Vladimir Oltean <olteanv@gmail.com> Date: Thu, 7 May 2020 19:07:32 +0300 > What does it mean that this series is "deferred" in patchwork? I need it to be reviewed, nobody reviewed it for days so I just toss it in the deferred state. I don't feel comfortable applying this without Andrew/Florian's review, but if that doesn't happen I don't want this series clogging up my backlog so I toss it because you can always repost after some time.
On 5/7/2020 3:15 PM, David Miller wrote: > From: Vladimir Oltean <olteanv@gmail.com> > Date: Thu, 7 May 2020 19:07:32 +0300 > >> What does it mean that this series is "deferred" in patchwork? > > I need it to be reviewed, nobody reviewed it for days so I just toss > it in the deferred state. > > I don't feel comfortable applying this without Andrew/Florian's > review, but if that doesn't happen I don't want this series clogging > up my backlog so I toss it because you can always repost after > some time. I should be able to review those patches later today and give them a spin too.
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. 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/ 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(-)