netdev - Re: Crosschip bridge functionality

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 3 Jan 2023 12:47:29 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Colin Foster <colin.foster@...advantage.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        netdev@...r.kernel.org
Subject: Re: Crosschip bridge functionality

On Sat, Dec 24, 2022 at 10:53:10AM -0800, Colin Foster wrote:
> > That being said, you need to broaden your detection criteria for cross-chip
> > bridging; sja1105 (and tag_8021q in general) supports this too, except
> > it's a bit hidden from the ds->ops->crosschip_bridge_join() operation.
> > It all relies on the concept of cross-chip notifier chain from switch.c.
> > dsa_tag_8021q_bridge_join() will emit a DSA_NOTIFIER_TAG_8021Q_VLAN_ADD
> > event, which the other tag_8021q capable switches in the system will see
> > and react to.
> > 
> > Because felix and sja1105 each support a tagger based on tag_8021q for
> > different needs, there is an important difference in their implementations.
> > The comment in dsa_tag_8021q_bridge_join() - called by sja1105 but not
> > by felix - summarizes the essence of the difference.
> 
> Hmm... So the Marvell and sja1105 both support "Distributed" but in
> slightly different ways?

Yes, the SJA1105 and SJA1110 switches can also be instantiated multiple
times on the same board (under the same DSA master, forming a single tree),
and have some awareness of each other. The hardware awareness is limited
to PTP timestamping. Only leaf ports should take a MAC timestamp for a
PTP event message. Cascade ports must be configured to forward that
packet timestamp to the CPU and not generate a new one. Otherwise, the
forwarding plane is basically unaware of a multi-switch DSA tree.
The reasoning of the designers was that it doesn't even need to be,
since non-proprietary mechanisms such as VLANs can be used to restrict
the forwarding domain as desired. The cross-chip support in tag_8021q
follows that idea and programs some reserved VLANs to the ports that
need them.