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

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

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?
-- 
Florian