Messages in this thread | | | Subject | Re: [PATCH v2 net-next 05/15] net: dsa: sja1105: save/restore VLANs using a delta commit method | From | Florian Fainelli <> | Date | Mon, 11 May 2020 20:31:43 -0700 |
| |
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > Managing the VLAN table that is present in hardware will become very > difficult once we add a third operating state > (best_effort_vlan_filtering). That is because correct cleanup (not too > little, not too much) becomes virtually impossible, when VLANs can be > added from the bridge layer, from dsa_8021q for basic tagging, for > cross-chip bridging, as well as retagging rules for sub-VLANs and > cross-chip sub-VLANs. So we need to rethink VLAN interaction with the > switch in a more scalable way. > > In preparation for that, use the priv->expect_dsa_8021q boolean to > classify any VLAN request received through .port_vlan_add or > .port_vlan_del towards either one of 2 internal lists: bridge VLANs and > dsa_8021q VLANs. > > Then, implement a central sja1105_build_vlan_table method that creates a > VLAN configuration from scratch based on the 2 lists of VLANs kept by > the driver, and based on the VLAN awareness state. Currently, if we are > VLAN-unaware, install the dsa_8021q VLANs, otherwise the bridge VLANs. > > Then, implement a delta commit procedure that identifies which VLANs > from this new configuration are actually different from the config > previously committed to hardware. We apply the delta through the dynamic > configuration interface (we don't reset the switch). The result is that > the hardware should see the exact sequence of operations as before this > patch. > > This also helps remove the "br" argument passed to > dsa_8021q_crosschip_bridge_join, which it was only using to figure out > whether it should commit the configuration back to us or not, based on > the VLAN awareness state of the bridge. We can simplify that, by always > allowing those VLANs inside of our dsa_8021q_vlans list, and committing > those to hardware when necessary. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> -- Florian
| |