Message-ID: <20240507201827.47suw4fwcjrbungy@skbuf>
Date: Tue, 7 May 2024 23:18:27 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Marek Behún <kabel@...nel.org>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH net-next v2 2/2] net: dsa: update the unicast MAC address
 when changing conduit

Hi Marek,

On Thu, May 02, 2024 at 02:29:22PM +0200, Marek Behún wrote:
> When changing DSA user interface conduit while the user interface is up,
> DSA exhibits different behavior in comparison to when the interface is
> down. This different behavior concers the primary unicast MAC address

nitpick: concerns

> stored in the port standalone FDB and in the conduit device UC database.
> 
> If we put a switch port down while changing the conduit with
>   ip link set sw0p0 down
>   ip link set sw0p0 type dsa conduit conduit1
>   ip link set sw0p0 up
> we delete the address in dsa_user_close() and install the (possibly
> different) address in dsa_user_open().
> 
> But when changing the conduit on the fly, the old address is not
> deleted and the new one is not installed.
> 
> Since we explicitly want to support live-changing the conduit, uninstall
> the old address before calling dsa_port_assign_conduit() and install the
> (possibly different) new address after the call.
> 
> Because conduit change might also trigger address change (the user
> interface is supposed to inherit the conudit interface MAC address if no

nitpick: conduit

> address is defined in hardware (dp->mac is a zero address)), move the
> eth_hw_addr_inherit() call from dsa_user_change_conduit() to
> dsa_port_change_conduit(), just before installing the new address.
> 
> Fixes: 95f510d0b792 ("net: dsa: allow the DSA master to be seen and changed through rtnetlink")
> Signed-off-by: Marek Behún <kabel@...nel.org>
> ---

Sorry for the delay. I've tested this change and basically, while there
is clearly a bug, that bug produces no adverse effects / cannot be
reproduced with felix (the only mainline driver with the feature to
change conduits). So it could be sent to 'net-next' rather that 'net' on
that very ground, if there is no other separate reason for this to go to
stable kernels anyway, I guess.

There are 2 reasons why with felix the bug does not manifest itself.

First is because both the 'ocelot' and the alternate 'ocelot-8021q'
tagging protocols have the 'promisc_on_conduit = true' flag. So the
unicast address doesn't have to be in the conduit's RX filter - neither
the old or the new conduit.

Second, dsa_user_host_uc_install() theoretically leaves behind host FDB
entries installed towards the wrong (old) CPU port. But in felix_fdb_add(),
we treat any FDB entry requested towards any CPU port as if it was a
multicast FDB entry programmed towards _all_ CPU ports. For that reason,
it is installed towards the port mask of the PGID_CPU port group ID:

	if (dsa_port_is_cpu(dp))
		port = PGID_CPU;

It would be great if this clarification would be made in the commit
message, to give the right impression to backporters seeking a correct
bug impact assessment.

BTW, I'm curious how this is going to be handled with Marvell. Basically
if all switch Ethernet interfaces have the same MAC address X which
_isn't_ inherited from their respective conduit (so it is preserved when
changing conduit), and you have a split conduit configuration like this:
- half the user ports are under eth0
- half the user ports are under eth1

then you have a situation where MAC address X needs to be programmed as
a host FDB entry both towards the CPU port next to eth0, and towards
that next to eth1.

There isn't any specific "core awareness" in DSA about the way in which
host FDB entries towards multiple CPU ports are handled in the Felix case.
So the core ends up having a not very good idea of what's happening
behind the scenes, and basically requests a migration from the old CPU
port to the new one, when in reality none takes place. I'm wondering how
things are handled in your new code; maybe we need to adapt the core
logic if there is a second implementation that's similar to felix in
this regard. Basically I'm saying that dsa_user_host_uc_install() may
not need to call dsa_port_standalone_host_fdb_add() when changing
conduit, if we had dedicated DSA API for .host_fdb_add() rather than
.port_fdb_add(port == CPU port).

Anyway, I was able to coerce the code (with extra patches) into validating
that your patch works on a driver that hypothetically does things a bit
differently than felix. So, with the commit message reorganized:

Reviewed-by: Vladimir Oltean <olteanv@...il.com>
Tested-by: Vladimir Oltean <olteanv@...il.com>

Powered by blists - more mailing lists