Message-ID: <9150c268-d5c5-53ba-babe-17fe8ed6bce4@bang-olufsen.dk>
Date:   Thu, 7 Oct 2021 14:15:23 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Vladimir Oltean <vladimir.oltean@....com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: DSA: some questions regarding TX forwarding offload

On 10/7/21 1:34 PM, Vladimir Oltean wrote:
> On Thu, Oct 07, 2021 at 11:22:32AM +0000, Alvin Šipraga wrote:
>>>> 	spa: source port address, i.e. the port that learned
>>>> 	fid: FID (of the VLAN)
>>>> 	efid: EFID (of the port)
>>>>
>>>> I also tried sending untagged frames from the network and cycling
>>>> through one of the VLANs as PVID, in which case the port would learn and
>>>> make an entry with vid_fid corresponding to the PVID.
>>>>
>>>> This suggests to me that the IVL field of the VLAN configuration really
>>>> does achieve Independent VLAN learning, and that there are not many
>>>> constraints here besides the size of the look-up-table.
>>>
>>> Can you repeat the experiment sweeping through EFIDs, but with the VLANs
>>> configured for SVL and having the same FID? I would expect that the LUT
>>> indices will be different, but still as many. Just want to confirm my
>>> theory that the EFID provides port-based isolation regardless of IVL_EN.
>>
>> I was actually testing this just now.
>>
>> For VLANs with SVL same FID and EFID, the same MAC is learned into the
>> same index, irrespective of VID (no surprise).
>>
>> However, cycling through the EFID, the same MAC is instead learned into
>> 8 different indices.
>>
>> So yes, EFID provides port-based isolation regardless of IVL_EN. This is
>> consistent with the description in the datasheet too.
> 
> Ok, so the EFID will be the basis for FDB isolation then. An EFID for
> all standalone ports, and an EFID for each bridge.

OK, thanks for your patience thus far. I have just one more set of 
questions, this time regarding VLAN-unaware bridges.

First of all, I noticed that even with VLAN-unaware bridges, if I add 
VLANs to the bridge or ports, then my .port_vlan_add is called even 
though VLAN filtering is not enabled. That's OK and the switch will 
still receive untagged/priority-tagged frames without complaint. But if 
I may ask, what is the point? Even when programming a PVID on a given 
port of a VLAN-unaware bridge, the switch is not inserting 802.1Q tags 
on ingress frames that it forwards to the CPU port (tcpdump on the swpN 
interface still shows untagged frames). So I fail to see what capability 
is being offloaded to the switch hardware with that call to 
.port_vlan_add for VLAN-unaware bridges. Or _should_ the switch insert a 
tag for ports with a PVID?

The second concern I have is regarding learning. We agreed now that all 
of the VLANs we add to the switch should have IVL_EN=1, meaning that the 
switch will learn in a VLAN-aware manner. If the switch receives a frame 
with MAC SA=00:00:aa:aa:aa:aa, VID=1 on port N of a VLAN-unaware bridge, 
it will still have to flood a frame from the CPU with MAC 
DA=00:00:aa:aa:aa:aa if the frame doesn't have VID=1, rather than 
forwarding it directly to port N. So although the ports of this 
VLAN-unaware bridge are respecting the rules of VLAN-(un)awareness as I 
read them in the switchdev documentation, the hardware's learning 
process is still VLAN-aware and may cause more flooding than expected. 
My question to you is: is this acceptable behaviour?

To work around this, I guess I can set vlan_filtering_is_global=true. Or 
I can do some bookkeeping in the driver of VLAN settings and only 
program them when enabling VLAN filtering, which is a bit of a pain. 
Hoping you can help clear this up for me - I have a feeling I have 
misunderstood something.

Powered by blists - more mailing lists