[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hpmr9Wey7SV9wLhE--VCSO=vobkqNW_kOB8c+DHE_Zs6g@mail.gmail.com>
Date: Thu, 7 May 2020 19:07:32 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
"David S. Miller" <davem@...emloft.net>
Cc: Jiri Pirko <jiri@...nulli.us>, Ido Schimmel <idosch@...sch.org>,
Jakub Kicinski <kuba@...nel.org>,
netdev <netdev@...r.kernel.org>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Mingkai Hu <mingkai.hu@....com>
Subject: Re: [PATCH v3 net-next 0/4] Cross-chip bridging for disjoint DSA trees
Hi David,
On Mon, 4 May 2020 at 01:12, Vladimir Oltean <olteanv@...il.com> wrote:
>
> From: Vladimir Oltean <vladimir.oltean@....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
Powered by blists - more mailing lists