Re: [RFC PATCH net-next] net: dsa: tag_8021q: Allow DSA tags and VLAN filtering simultaneously

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

On 11/21/19 2:29 AM, Vladimir Oltean wrote:
> On Mon, 18 Nov 2019 at 06:30, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 11/17/2019 1:14 PM, Vladimir Oltean wrote:
>> [snip]
>>
>>> +best_effort_vlan_filtering
> 
> [snip]
> 
>>> +                     - Cannot terminate VLAN-tagged traffic on local device.
>>> +                       There is no way to deduce the source port from these.
>>> +                       One could still use the DSA master though.
>>
>> Could we use QinQ to possibly solve these problems and would that work
>> for your switch? I do not really mind being restricted to not being able
>> to change the default_pvid or have a reduced VLAN range, but being able
>> to test VLAN tags terminated on DSA slave network devices is a valuable
>> thing to do.
>> --
>> Florian
> 
> I took another look at the hardware manual and there exists a feature
> called the Retagging Table whose purpose I did not understand
> originally. It can do classification on frames with a given { ingress
> port mask, egress port mask, vlan id }, and clone them towards a given
> list of destination ports with a new VID. The table only has space for
> 32 entries though. I think I can use it to keep the CPU copied to all
> non-pvid VLANs received on the front-panel ports. The CPU will still
> see a pvid-tagged frame for each of those, but with the PCP from the
> original frame. The result is that VLAN filtering is still performed
> correctly (non-member VIDs of the front-panel ports are dropped), but
> the tag is consumed by DSA and sockets still see those frames as
> untagged. To me that's fine except for the fact that the CPU will now
> be spammed by offloaded flows even if the switch learns the
> destination to be a front-panel. Just wanted to hear your opinion
> before attempting to prototype this.

That seems like a good idea to me. Back to your RFC patch here, instead
of introducing a "best effort vlan filtering" configuration knob, how
about just restricting the possible VID range when vlan_filtering=1
through the port_vlan_prepare() callback to exclude the problematic
dsa_tag_8021q VID ranges used for port discrimination?
-- 
Florian