Re: [PATCH net] net: dsa: b53: be VLAN unaware when not filtering
Semih Baskan <[email protected]>
| Newsgroups | gmane.linux.network,gmane.linux.kernel |
|---|---|
| Message-ID | <CAAsRjRktfP0gM4qe0d7gtRg_oQXUu4FFh4Y9Zm+bRHL5Ow7hKw@mail.gmail.com> |
Hi Jonas, On Thu, Aug 13, 2026 at 10:08 AM Jonas Gorski <[email protected]> wrote: > Right, that would be the quick workaround to allow functionality. We > just need to not mark them as forwarded, as DROP_VTABLE_MISS=0 will > have them sent to CPU already. On bcm5301x, miss frames reach the CPU only with port 8 as the sole management port. All measured on the BCM53011, DROP_VTABLE_MISS=0 throughout: - In-tree topology (port 5 as CPU): a tagged frame with a VID absent from the VLAN table reaches no CPU port, 0 of 7. Already reported in the offload series thread. - All three CPU ports enabled per the in-tree bcm-ns.dtsi, with Rafal's V3 patches 1 and 2 applied so DSA prefers port 8, measured yesterday: still 0 of 7. GMNGCFG reads 0xc2, dual IMP mode, and in that mode the miss path delivers to no port at all; bringing the port 5 conduit up or down changes nothing. - Port 8 as the ONLY enabled CPU port (FRM_MNGP=0b10): miss frames are delivered to the CPU, indiscriminately. So a software bridging fallback that relies on miss-to-CPU delivery works on chips like BCM63268/BCM53115, where you measured the CPU copy, but on bcm5301x it additionally requires either a single IMP DT (disabling ports 5 and 7, as the Netgear R8000 and Linksys Panamera do today) or driver code that forces FRM_MNGP to 0b10 when port 8 is the conduit. Rafal's pending "ARM: dts: BCM5301X: Enable extra CPU ports for Netgear R8000" re-enables those two ports on the R8000. On the port 5 DTs it would receive nothing. Best regards, Semih