Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
On Tue, Feb 2, 2021 at 6:15 AM DENG Qingfang wrote:
>
> Marvell Link Street switch series cannot perform MAC learning from
> CPU-injected (FROM_CPU) DSA frames, which results in 2 issues.
> - excessive flooding, due to the fact that DSA treats those addresses
> as unknown
> - the risk of stale routes, which can lead to temporary packet loss
>
> Backport those patch series from netdev mailing list, which solve these
> issues by adding and clearing static entries to the switch's FDB.
>
> Add a hack patch to set default VID to 1 in port_fdb_{add,del}. Otherwise
> the static entries will be added to the switch's private FDB if VLAN
> filtering disabled, which will not work.
>
> Link:
> https://lore.kernel.org/netdev/20210106095136.224739-1-olte...@gmail.com/
> Link:
> https://lore.kernel.org/netdev/20210116012515.3152-1-tob...@waldekranz.com/
> Link: https://lore.kernel.org/netdev/20210130134334.10243-1-dqf...@gmail.com/
> Ref: https://gitlab.nic.cz/turris/turris-build/-/issues/165
> Signed-off-by: DENG Qingfang
Tested-by: Eneas U de Queiroz
I have tested this using WRT3200ACM, and it solves the problem of
clients not able to roam from one AP to the another--my APs are wired,
not using WDS. Clients would not be able to communicate for 300s
after roaming from one AP to another. I consider this a critical bug,
so a fix must be included before 2021.02 branches. I have applied the
patch to 3 APs, and have been using them for days without any real
issue--I'm not considering the 'ATU member violation' messages
reported earlier an issue, as they do appear to be harmless.
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
Happy Friday! I've been using this patchset for 10 days now without issue. It has been available on my builds since then and I've had no issues reported. I've also seen a handful others on the OpenWrt forum make use of it. Of note, 776-v5.12-net-dsa-mv88e6xxx-override-portvec-if-unicast.patch needs to be dropped as it has been merged into Linux 5.4.97. Regards, Tad. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
On Wed, Feb 3, 2021 at 4:20 PM Tobias Waldekranz wrote: > > AFAIK, no. There is a per-port bit that you can set to ignore the > errors, i.e. no violation is generated, but I am pretty sure that the > frame is still dropped. I just tested on my WRT1900AC v2. It seems that the CPU can receive those frames just fine. So it is safe to disable the ATU warnings, at least for OpenWrt. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
On Tue Feb 2, 2021 at 11:03 PM CET, DENG Qingfang wrote: > On Tue, Feb 2, 2021 at 9:22 PM Tobias Waldekranz > wrote: > > > > > > > > Tobias, what happens if the switch receives a frame that violates ATU > > > portvec member? Is the frame trapped to the CPU or dropped? > > > > The frame will be dropped. So the flow will be blocked until the DSA > > driver removes the static entry. Once the it has been removed, the > > switch is free to learn it in the normal way again. > > Can the switch be configured to trap those frames to the CPU? So the > bridge subsystem can handle them. AFAIK, no. There is a per-port bit that you can set to ignore the errors, i.e. no violation is generated, but I am pretty sure that the frame is still dropped. This is why you really want the CPU to send FORWARDs. That way, the switch can handle all aging entries. It is on my TODO, but it is not obvious how to get the bridge to cooperate. > > > > But I would strongly advise against removing the message as it often > > provides important clues when debugging connectivity issues. > > Use dev_dbg_ratelimited instead? Today it uses dev_err_ratelimited, which seems sensible to me. My guess is 99% of users won't have debug messages compiled in, so that is essentially the same as removing it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
On Tue, Feb 2, 2021 at 9:22 PM Tobias Waldekranz wrote: > > > > > Tobias, what happens if the switch receives a frame that violates ATU > > portvec member? Is the frame trapped to the CPU or dropped? > > The frame will be dropped. So the flow will be blocked until the DSA > driver removes the static entry. Once the it has been removed, the > switch is free to learn it in the normal way again. Can the switch be configured to trap those frames to the CPU? So the bridge subsystem can handle them. > > But I would strongly advise against removing the message as it often > provides important clues when debugging connectivity issues. Use dev_dbg_ratelimited instead? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
On Tue Feb 2, 2021 at 9:31 PM CET, DENG Qingfang wrote: > On Tue, Feb 2, 2021 at 8:14 PM Tad wrote: > > > > I've tested this working well! > > Devices can roam during iperf with no loss! > > Thank you! > > > > > > There are some errors in dmesg: > > wrt1900acv1 > > mv88e6085 f1072004.mdio-mii:00: ATU member violation for [mac] portvec 20 > > spid 3 > > > > wrt1200ac > > mv88e6085 f1072004.mdio-mii:00: ATU member violation for [mac] portvec 40 > > spid 3 > > > > are those expected? > > I think so. When your client moves back to the switch ports, the > static entry in the ATU still points to the CPU port, so it triggers > an ATU member violation interrupt. DSA will clear the static entry > afterward so it is not fatal. > > Tobias, what happens if the switch receives a frame that violates ATU > portvec member? Is the frame trapped to the CPU or dropped? The frame will be dropped. So the flow will be blocked until the DSA driver removes the static entry. Once the it has been removed, the switch is free to learn it in the normal way again. > Is it okay to suppress this warning? It depends on what you mean by suppress. It is harmless in the sense that the driver will rectify the situation ASAP, so it can safely be _ignored_ in this scenario. But I would strongly advise against removing the message as it often provides important clues when debugging connectivity issues. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
On Tue, Feb 2, 2021 at 8:14 PM Tad wrote: > > I've tested this working well! > Devices can roam during iperf with no loss! > Thank you! > > > There are some errors in dmesg: > wrt1900acv1 > mv88e6085 f1072004.mdio-mii:00: ATU member violation for [mac] portvec 20 > spid 3 > > wrt1200ac > mv88e6085 f1072004.mdio-mii:00: ATU member violation for [mac] portvec 40 > spid 3 > > are those expected? I think so. When your client moves back to the switch ports, the static entry in the ATU still points to the CPU port, so it triggers an ATU member violation interrupt. DSA will clear the static entry afterward so it is not fatal. Tobias, what happens if the switch receives a frame that violates ATU portvec member? Is the frame trapped to the CPU or dropped? Is it okay to suppress this warning? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
I've tested this working well! Devices can roam during iperf with no loss! Thank you! There are some errors in dmesg: wrt1900acv1 mv88e6085 f1072004.mdio-mii:00: ATU member violation for [mac] portvec 20 spid 3 wrt1200ac mv88e6085 f1072004.mdio-mii:00: ATU member violation for [mac] portvec 40 spid 3 are those expected? Regards, Tad. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: DSA roaming fix for Marvell Link Street switch series
Marvell Link Street switch series cannot perform MAC learning from
CPU-injected (FROM_CPU) DSA frames, which results in 2 issues.
- excessive flooding, due to the fact that DSA treats those addresses
as unknown
- the risk of stale routes, which can lead to temporary packet loss
Backport those patch series from netdev mailing list, which solve these
issues by adding and clearing static entries to the switch's FDB.
Add a hack patch to set default VID to 1 in port_fdb_{add,del}. Otherwise
the static entries will be added to the switch's private FDB if VLAN
filtering disabled, which will not work.
Link: https://lore.kernel.org/netdev/20210106095136.224739-1-olte...@gmail.com/
Link:
https://lore.kernel.org/netdev/20210116012515.3152-1-tob...@waldekranz.com/
Link: https://lore.kernel.org/netdev/20210130134334.10243-1-dqf...@gmail.com/
Ref: https://gitlab.nic.cz/turris/turris-build/-/issues/165
Signed-off-by: DENG Qingfang
---
...y-switchdev-of-disappearance-of-old-.patch | 126 +
...r-when-a-non-legacy-FDB-operation-fa.patch | 52
...e-switchdev_notifier_fdb_info-in-dsa.patch | 226 +++
...tchdev-event-implementation-under-th.patch | 85 ++
...ly-in-dsa_slave_switchdev_event-if-w.patch | 42 +++
...or-SWITCHDEV_-FDB-DEL-_ADD_TO_DEVICE.patch | 263 ++
...v88e6xxx-override-portvec-if-unicast.patch | 35 +++
.../710-net-dsa-mv88e6xxx-default-VID-1.patch | 18 ++
...hdev-Refactor-br_switchdev_fdb_notif.patch | 71 +
...hdev-Include-local-flag-in-FDB-notif.patch | 42 +++
...hdev-Send-FDB-notifications-for-host.patch | 94 +++
...local-addresses-in-assisted-CPU-port.patch | 36 +++
...bridge-addresses-in-assisted-CPU-por.patch | 30 ++
...tic-FDB-entries-on-foreign-interface.patch | 56
...equest-assisted-learning-on-CPU-port.patch | 27 ++
15 files changed, 1203 insertions(+)
create mode 100644
target/linux/generic/backport-5.4/770-v5.12-net-bridge-notify-switchdev-of-disappearance-of-old-.patch
create mode 100644
target/linux/generic/backport-5.4/771-v5.12-net-dsa-be-louder-when-a-non-legacy-FDB-operation-fa.patch
create mode 100644
target/linux/generic/backport-5.4/772-v5.12-net-dsa-don-t-use-switchdev_notifier_fdb_info-in-dsa.patch
create mode 100644
target/linux/generic/backport-5.4/773-v5.12-net-dsa-move-switchdev-event-implementation-under-th.patch
create mode 100644
target/linux/generic/backport-5.4/774-v5.12-net-dsa-exit-early-in-dsa_slave_switchdev_event-if-w.patch
create mode 100644
target/linux/generic/backport-5.4/775-v5.12-net-dsa-listen-for-SWITCHDEV_-FDB-DEL-_ADD_TO_DEVICE.patch
create mode 100644
target/linux/generic/backport-5.4/776-v5.12-net-dsa-mv88e6xxx-override-portvec-if-unicast.patch
create mode 100644
target/linux/generic/hack-5.4/710-net-dsa-mv88e6xxx-default-VID-1.patch
create mode 100644
target/linux/generic/pending-5.4/762-net-bridge-switchdev-Refactor-br_switchdev_fdb_notif.patch
create mode 100644
target/linux/generic/pending-5.4/763-net-bridge-switchdev-Include-local-flag-in-FDB-notif.patch
create mode 100644
target/linux/generic/pending-5.4/764-net-bridge-switchdev-Send-FDB-notifications-for-host.patch
create mode 100644
target/linux/generic/pending-5.4/765-net-dsa-Include-local-addresses-in-assisted-CPU-port.patch
create mode 100644
target/linux/generic/pending-5.4/766-net-dsa-Include-bridge-addresses-in-assisted-CPU-por.patch
create mode 100644
target/linux/generic/pending-5.4/767-net-dsa-Sync-static-FDB-entries-on-foreign-interface.patch
create mode 100644
target/linux/generic/pending-5.4/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch
diff --git
a/target/linux/generic/backport-5.4/770-v5.12-net-bridge-notify-switchdev-of-disappearance-of-old-.patch
b/target/linux/generic/backport-5.4/770-v5.12-net-bridge-notify-switchdev-of-disappearance-of-old-.patch
new file mode 100644
index 00..df4e74cd96
--- /dev/null
+++
b/target/linux/generic/backport-5.4/770-v5.12-net-bridge-notify-switchdev-of-disappearance-of-old-.patch
@@ -0,0 +1,126 @@
+From 90dc8fd36078a536671adae884d0b929cce6480a Mon Sep 17 00:00:00 2001
+From: Vladimir Oltean
+Date: Wed, 6 Jan 2021 11:51:30 +0200
+Subject: [PATCH] net: bridge: notify switchdev of disappearance of old FDB
+ entry upon migration
+
+Currently the bridge emits atomic switchdev notifications for
+dynamically learnt FDB entries. Monitoring these notifications works
+wonders for switchdev drivers that want to keep their hardware FDB in
+sync with the bridge's FDB.
+
+For example station A wants to talk to station B in the diagram below,
+and we are concerned with the behavior of the bridge on the DUT device:
+
+ DUT
+ +-+
+ | br0 |
+ | +--+ +--+ +--+ +--+ |
+ | | | | | | | | | |
+ | | swp0 | | swp1 | | swp2 | | eth0 | |
+ +-+
+ || |
+
