Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

[netdev]

On 2022-07-17 17:08, Vladimir Oltean wrote:
> On Sun, Jul 17, 2022 at 04:57:50PM +0200, netdev@xxxxxxxxxxxxxxxxxxxx 
> wrote:
> > Maybe I am just trying to understand the problem you are posing, so 
> > afaics
> > MAC addresses should be unique and having the same MAC address behind 
> > a
> > locked port and a not-locked port seems like a mis-configuration 
> > regardless
> > of vlan setup? As the zero-DPV entry only blocks the specific SA MAC 
> > on a
> > specific vlan, which is behind a locked port, there shouldn't be any
> > problem...?
> >
> > If the host behind a locked port starts sending on another vlan than 
> > where
> > it got the first locked entry, another locked entry will occur, as the
> > locked entries are MAC + vlan.
>
> I don't think it's an invalid configuration, I have a 17-port Marvell
> switch which I use as infrastructure to connect my PC with my board 
> farm
> and to the Internet. I've cropped 4 out of those 17 ports for use in
> selftests, effectively now having 2 bridges (br0 used by the selftests
> and br-lan for systemd-networkd).
>
> Currently all the traffic sent and received by the selftests is done
> through lan1-lan4, but if I wanted to run some bridge locked port tests
> with traffic from my PC, what I'd do is I'd connect a (locked) port 
> from br0
> to a port from br-lan, and my PC would thus gain indirect connectivity 
> to the
> locked port.
>
> Then I'd send a packet and the switch would create a locked FDB entry
> for my PC's MAC address, but that FDB entry would span across the 
> entire
> MV88E6XXX_FID_BRIDGED, so practically speaking, it would block my PC's
> MAC address from doing anything, including accessing the Internet, i.e.
> traffic that has nothing at all to do with the locked port in br0.
> That isn't quite ok.

Okay, I see the problem you refer to. I think that we have to accept 
some limitations unless you think that just zeroing the specific port 
bit in the DPV would be a better solution, and there wouldn't be caveats 
with that besides having to do a FDB search etc to get the correct DPV 
if I am not too mistaken.

Also trunk ports is a limitation as that is not supported in this 
implementation.