Re: DSA: some questions regarding TX forwarding offload

Alvin Šipraga
2021-10-07T14:15:31Z

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.