On 11/02/2026 11:26, Daniel Golle wrote:
On Wed, Feb 11, 2026 at 11:13:26AM +0100, Caleb James DeLisle wrote:
On 10/02/2026 23:12, Benjamin Larsson wrote:
If I understand correct, the ref SDK just sets up a transparent bridge
and lets the packets flow through? If that is correct is that an option
here?
When use_soc_lan is unset, this is what happens. When use_soc_lan is set, it
does a bunch of highly awkward stuff to add support for one extra port on
the internal switch. It's an option, probably to treat the internal switch
as part of the eth driver - however this will not work on EN7526C which no
external switch, internal is exposed.
And IMO we should not stack stags. If it is possible to pass stags
through with the pass-through bit intact it should be possible to
address all ports on both switches with just one stag.
I was hoping the PT_OPTION PVC bit would set the stag pass through bit
on incoming frames.
Stacking stags does potentially have a performance penalty in the tag parser
- I say "potentially" because it's already walking a list which could be an
array index, and even 2 array indexes is faster than what we have now.
But trying to use the PT bit as designed makes it impossible to
differentiate between a packet that came from port N of the external switch
and a packet that came from port N of the internal. Vendor code doesn't
support having the same port number active on both internal and external, if
you try it will quietly overwrite the switch_port_map entry in
init_ethernet_port_map(), so I surmise this is a real silicon bug, not a
misconfiguration on my end.
But (so far), stacking tags seems to work, so I would much prefer it to
inter-switch rules, i.e. "you can't enable this port in the DT because you
have one with the same number on the other switch".
So if the vendor SDK doesn't allow using the same port number on both,
the on-die and the MCM switch, that means there won't be any boards
around doing that, right? Nobody is designing new boards with this
silicon at this point, all existing boards had to adhere to those rules.
Hence I don't see why the extra overhead of stacked special tags would
be worth it, especially also given that stacked special tags also won't
work with the hardware offloading PPE/HWNAT, and likely also break other
stuff such as TX checksum offloading.
BTW Vendor code (see: TCSUPPORT_MULTI_SWITCH_EXT) suggests there are boards
with multiple external switches. Probably a board integrator hung another
7530 off of one of the RGMII interfaces. Per my reading, vendor code falls
back on VLANs, giving up on the stag entirely. I haven't confirmed that
transmit works yet, but assuming it does, stacked stags should Just Work in
this use case whereas the PT bit clearly would not.
Have you seen any boards actually using an additional (ie. third) MT7530
connected as external IC? If this feature is only a theoretical option
which none of the board markers choose to implement I think it's worth
ignoring it and not supporting it upstream, especially if the vendor SDK
just uses the swconfig driver with VLANs rather than DSA.
Okay, I'll put a "no port reuse" check in mt7530.c and in tag_mtk.c I'll
just the dsa_conduit_find_user() with a relaxed walker that ignores
switch ID, then make mtk_tag_xmit() set the PT bit if switch ID is
non-zero. Chaining will support 1 downstream switch on port 5, and any
port used on one switch cannot be used on the other.
Thanks,
Caleb
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
