Date:   Tue, 3 Mar 2020 10:02:31 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        netdev <netdev@...r.kernel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH v3 net-next 2/2] net: dsa: felix: Allow unknown unicast
 traffic towards the CPU port module

On 3/3/20 8:04 AM, Vladimir Oltean wrote:
> On Sat, 29 Feb 2020 at 16:50, Vladimir Oltean <olteanv@...il.com> wrote:
>>
>> From: Vladimir Oltean <vladimir.oltean@....com>
>>
>> Compared to other DSA switches, in the Ocelot cores, the RX filtering is
>> a much more important concern.
>>
>> Firstly, the primary use case for Ocelot is non-DSA, so there isn't any
>> secondary Ethernet MAC [the DSA master's one] to implicitly drop frames
>> having a DMAC we are not interested in.  So the switch driver itself
>> needs to install FDB entries towards the CPU port module (PGID_CPU) for
>> the MAC address of each switch port, in each VLAN installed on the port.
>> Every address that is not whitelisted is implicitly dropped. This is in
>> order to achieve a behavior similar to N standalone net devices.
>>
>> Secondly, even in the secondary use case of DSA, such as illustrated by
>> Felix with the NPI port mode, that secondary Ethernet MAC is present,
>> but its RX filter is bypassed. This is because the DSA tags themselves
>> are placed before Ethernet, so the DMAC that the switch ports see is
>> not seen by the DSA master too (since it's shifter to the right).
>>
>> So RX filtering is pretty important. A good RX filter won't bother the
>> CPU in case the switch port receives a frame that it's not interested
>> in, and there exists no other line of defense.
>>
>> Ocelot is pretty strict when it comes to RX filtering: non-IP multicast
>> and broadcast traffic is allowed to go to the CPU port module, but
>> unknown unicast isn't. This means that traffic reception for any other
>> MAC addresses than the ones configured on each switch port net device
>> won't work. This includes use cases such as macvlan or bridging with a
>> non-Ocelot (so-called "foreign") interface. But this seems to be fine
>> for the scenarios that the Linux system embedded inside an Ocelot switch
>> is intended for - it is simply not interested in unknown unicast
>> traffic, as explained in Allan Nielsen's presentation [0].
>>
>> On the other hand, the Felix DSA switch is integrated in more
>> general-purpose Linux systems, so it can't afford to drop that sort of
>> traffic in hardware, even if it will end up doing so later, in software.
>>
>> Actually, unknown unicast means more for Felix than it does for Ocelot.
>> Felix doesn't attempt to perform the whitelisting of switch port MAC
>> addresses towards PGID_CPU at all, mainly because it is too complicated
>> to be feasible: while the MAC addresses are unique in Ocelot, by default
>> in DSA all ports are equal and inherited from the DSA master. This adds
>> into account the question of reference counting MAC addresses (delayed
>> ocelot_mact_forget), not to mention reference counting for the VLAN IDs
>> that those MAC addresses are installed in. This reference counting
>> should be done in the DSA core, and the fact that it wasn't needed so
>> far is due to the fact that the other DSA switches don't have the DSA
>> tag placed before Ethernet, so the DSA master is able to whitelist the
>> MAC addresses in hardware.
>>
>> So this means that even regular traffic termination on a Felix switch
>> port happens through flooding (because neither Felix nor Ocelot learn
>> source MAC addresses from CPU-injected frames).
>>
>> So far we've explained that whitelisting towards PGID_CPU:
>> - helps to reduce the likelihood of spamming the CPU with frames it
>>   won't process very far anyway
>> - is implemented in the ocelot driver
>> - is sufficient for the ocelot use cases
>> - is not feasible in DSA
>> - breaks use cases in DSA, in the current status (whitelisting enabled
>>   but no MAC address whitelisted)
>>
>> So the proposed patch allows unknown unicast frames to be sent to the
>> CPU port module. This is done for the Felix DSA driver only, as Ocelot
>> seems to be happy without it.
>>
>> [0]: https://www.youtube.com/watch?v=B1HhxEcU7Jg
>>
>> Suggested-by: Allan W. Nielsen <allan.nielsen@...rochip.com>
>> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
>> ---
> 
> I see this patch has "Needs Review / ACK" in patchwork.
> 
> There is in fact a tag:
> 
> Reviewed-by: Allan W. Nielsen <allan.nielsen@...rochip.com>
> 
> which I had forgotten to copy over from v2:
> https://www.spinics.net/lists/netdev/msg633098.html
> 
> Hope there are no particular issues with this approach from DSA perspective.

Not really, until/if we implement UC and MC filtering on standalone DSA
ports, this will be revisited, but for now, this is what is expected.
-- 
Florian

Powered by blists - more mailing lists