staging: dpaa2-switch: properly setup switching domains
Until now, the DPAA2 switch was not capable to properly setup its switching domains depending on the existence, or lack thereof, of a upper bridge device. This meant that all switch ports of a DPSW object were switching by default even though they were not under the same bridge device. Another issue was the inability to actually add the CPU in the flooding domains (broadcast, unknown unicast etc) of a particular switch port. This meant that a simple ping on a switch interface was not possible since no broadcast ARP frame would actually reach the CPU queues. This patch tries to fix exactly these problems by: * Creating and managing a FDB table for each flooding domain. This means that when a switch interface is not bridged it will use its own FDB table. While in bridged mode all DPAA2 switch interfaces under the same upper will use the same FDB table, thus leverage the same FDB entries. * Adding a new MC firmware command - dpsw_set_egress_flood() - through which the driver can setup the flooding domains as needed. For example, when the switch interface is standalone, thus not in a bridge with any other DPAA2 switch port, it will setup its broadcast and unknown unicast flooding domains to only include the control interface (the queues that reach the CPU and the driver can dequeue from). This flooding domain changes when the interface joins a bridge and is configured to include, beside the control interface, all other DPAA2 switch interfaces. We impose a minimum limit of FDB tables available equal to the number of switch interfaces so that we guarantee that, in the maximal configuration - all interfaces are standalone, each switch port will have a private FDB table. At the same time, we only probe DPSW objects that have the flooding and broadcast replicators configured to be per FDB (DPSW_*_PER_FDB). Without this, the dpaa2-switch driver would not be able to configure multiple switching domains. At probe time, a FDB table will be allocated for each port. At a bridge join event, the switch port will either continue to use the current FDB table (if it's the first dpaa2-switch port to join that bridge) or will switch to use the FDB table associated with the port that it's already under the bridge. If a FDB switch is necessary, the private FDB table which was previously used will be returned to the pool of unused FDBs. Upon a bridge leave, the switch port needs a private FDB table thus it will search and get the first unused FDB table. This way, all the other ports remaining under the bridge will continue to use the same FDB table. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Showing
This diff is collapsed.
Please register or sign in to comment