Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Florian Fainelli <f.fainelli@gmail.com>]

On 5/6/2025 9:48 PM, Jonas Gorski wrote:
> On Tue, May 6, 2025 at 9:03 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>>
>>
>> On 5/6/2025 4:27 PM, Jonas Gorski wrote:
>>> On Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>>>>
>>>> / unrelated to patches /
>>>>
>>>> On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
>>>>>>> I have a fix/workaround for that, but as it is a bit more controversial
>>>>>>> and makes use of an unrelated feature, I decided to hold off from that
>>>>>>> and post it later.
>>>>>>
>>>>>> Can you expand on the fix/workaround you have?
>>>>>
>>>>> It's setting EAP mode to simplified on standalone ports, where it
>>>>> redirects all frames to the CPU port where there is no matching ARL
>>>>> entry for that SA and port. That should work on everything semi recent
>>>>> (including BCM63XX), and should work regardless of VLAN. It might
>>>>> cause more traffic than expected to be sent to the switch, as I'm not
>>>>> sure if multicast filtering would still work (not that I'm sure that
>>>>> it currently works lol).
>>>>>
>>>>> At first I moved standalone ports to VID 4095 for untagged traffic,
>>>>> but that only fixed the issue for untagged traffic, and you would have
>>>>> had the same issue again when using VLAN uppers. And VLAN uppers have
>>>>> the same issue on vlan aware bridges, so the above would be a more
>>>>> complete workaround.
>>>>
>>>> I don't understand the logic, can you explain "you would have had the
>>>> same issue again when using VLAN uppers"? The original issue, as you
>>>> presented it, is with bridges with vlan_filtering=0, and does not exist
>>>> with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
>>>> not committed to hardware RX filters. And bridges with mixed
>>>> vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
>>>> So I don't see how making VID 4095 be the PVID of just standalone ports
>>>> (leaving VLAN-unaware bridge ports with a different VID) would not be
>>>> sufficient for the presented problem.
>>>
>>> The issue isn't the vlan filtering, it's the (missing) FDB isolation
>>> on the ASIC.
>>
>> Could not we just use double tagging to overcome that limitation?
> 
> Wouldn't that break VLAN filtering on a vlan aware bridge? AFAICT
> double tagging mode is global, the VLAN table is then used for
> customer (port) assignment, so you can't filter on the inner/802.1Q
> tag anymore. Also learning would then essentially become SVL IIUCT.
> Also I think there aren't switches that support double tagging, but
> don't support EAP. EAP mode might be the easier way. Assuming there
> isn't a gotcha I have overlooked.

If EAP works, sure that seems like the way to go then.
-- 
Florian