Re: [PATCH v5 2/7] net: dsa: Add DSA driver for Hirschmann Hellcreek switches

On Mon Sep 07 2020, Vladimir Oltean wrote:

On Mon, Sep 07, 2020 at 08:05:25AM +0200, Kurt Kanzenbach wrote:

quoted

Well, that depends on whether hellcreek_vlan_add() is called for
creating that vlan interfaces. In general: As soon as both ports are
members of the same vlan that traffic is switched.

That's indeed what I would expect.
Not only that, but with your pvid-based setup, you only ensure port
separation for untagged traffic anyway.

Why? Tagged traffic is dropped unless the vlan is configured somehow. By
default, I've configured vlan 2 and 3 to reflect the port separation for
DSA. At reset the ports aren't members of any vlan.

We could also skip the initial VLAN configuration completely. At the end
of the day it's a TSN switch and the user will setup the vlan
configuration anyway.

I don't think you even need to call hellcreek_vlan_add() for VID 100
to be switched between ports, because your .port_vlan_filtering
callback does not in fact disable VLAN awareness, it just configures
the ports to not drop unknown VLANs. So, arguably, VLAN classification
is still performed. An untagged packet is classified to the PVID, a
tagged packet is classified to the VID in the packet. So tagged
packets bypass the separation.

So, I think that's not ok. I think the only proper way to solve this is
to inform the IP designers that VLANs are no substitute for a port
forwarding matrix (a lookup table that answers the question "can port i
forward to port j"). Switch ports that are individually addressable by
the network stack are a fundamental assumption of the switchdev
framework.

As I said before, there is no port forwarding matrix. There are only
vlans and the fdb. There's also a global flag for setting vlan unaware
mode and a port option for vlan tag required. That's it. I guess, we
have to deal with it somehow.

quoted

quoted

I remember asking in Message-ID: <20200716082935.snokd33kn52ixk5h@skbuf>
whether it would be possible for you to set
ds->configure_vlan_while_not_filtering = true during hellcreek_setup.
Did anything unexpected happen while trying that?

No, that comment got lost.

So looking at the flag: Does it mean the driver can receive vlan
configurations when a bridge without vlan filtering is used? That might
be problematic as this driver uses vlans for the port separation by
default. This is undone when vlan filtering is set to 1 meaning vlan
configurations can be received without any problems.

Yes.
Generally speaking, the old DSA behavior is something that we're trying
to get rid of, once all drivers set the option to true. So a new driver
should not rely on it even if it needs something like that.

OK. when a new driver should set the flag, then I'll set it. So, all
vlan requests programming requests should be "buffered" and executed
when vlan filtering is enabled? What is it good for?

Thanks,
Kurt