Re: Crosschip bridge functionality

[Vladimir Oltean <olteanv@gmail.com>]

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.