lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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