| Message ID | 20210728175327.1150120-1-dqfext@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mt7530 software fallback bridging fix | expand |
On Thu, Jul 29, 2021 at 01:53:24AM +0800, DENG Qingfang wrote: > DSA core has gained software fallback support since commit 2f5dc00f7a3e, > but it does not work properly on mt7530. This patch series fixes the > issues. I haven't looked at the patches, just read the commit messages. Your approach makes sense considering that mt7530 supports ACL rules. For switches that don't, I was thinking that we could add a check within DSA that bridging with software uppers such as LAGs can be allowed only as long as the bridge is VLAN-aware. If it is, then the classified VLAN for packets on standalone ports can be made == 0, and if independent VLAN learning is used, then the FDB entries learned on bridged ports will always have a VLAN ID != 0, so the standalone switch port won't attempt to shortcircuit the forwarding process towards the bridge port. Anyway, we can have both solutions, yours and the generic DSA restriction. I was just not expecting to see a fix for this already, it makes me think that the DSA restriction for VLAN-unaware software bridging should not be unconditional, but we should guard it behind a new bool option like ds->fdb_shared_across_all_ports = true or something like that. What do you think?
DSA core has gained software fallback support since commit 2f5dc00f7a3e, but it does not work properly on mt7530. This patch series fixes the issues. DENG Qingfang (2): net: dsa: tag_mtk: skip address learning on transmit to standalone ports net: dsa: mt7530: trap packets from standalone ports to the CPU drivers/net/dsa/mt7530.c | 28 ++++++++++++++++++++ drivers/net/dsa/mt7530.h | 56 ++++++++++++++++++++++++++++++++++++++++ net/dsa/tag_mtk.c | 6 ++--- 3 files changed, 87 insertions(+), 3 deletions(-)