Messages in this thread | | | Date | Thu, 29 Jul 2021 18:28:05 +0300 | From | Vladimir Oltean <> | Subject | Re: [RFC net-next 2/2] net: dsa: mt7530: trap packets from standalone ports to the CPU |
| |
On Thu, Jul 29, 2021 at 01:53:26AM +0800, DENG Qingfang wrote: > MT7530's FDB has 8 filter IDs, but they are only available for shared > VLAN learning, and all VLAN-unaware ports use 0 as the default filter > ID.
Actually, on second thought... If MT7530 supports 8 FIDs and it has 7 ports, then you can assign one FID to each standalone port or VLAN-unaware bridge it is a member of. The drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c driver has a similar concept, only instead of FID, it manages FDB IDs - each port is assigned to an FDB ID and it learns and looks up MAC addresses only within that FDB ID. Every standalone port uses its own fdb_id, and every port under the same bridge shares the same fdb_id (the fdb_id associated with a bridge is equal with the fdb_id of the first standalone port that joins that bridge; every other standalone port that joins a bridge will change its fdb_id to that of the bridge). When a port leaves a bridge and becomes standalone again, its fdb_id will again change to the first unused value. My point is that if you search for "fdb_id" in that driver you will maybe find some inspiration for how things like this can be managed. I know it's not 100% the same as your situation (the FDBs in the dpaa2-switch are selected by the VLAN table, and for that reason, the dpaa2-switch can only operate as VLAN-aware, and with shared VLAN learning per FDB), but the same concept can be reused, I think. With each port and VLAN-unaware bridge having its own FID, I think you will not have the shortcircuit issue any longer (and with VLAN-aware bridges you shouldn't have it anyway).
| |