---------- Forwarded message --------- From: David Bauer Date: Fri, Jun 23, 2023, 5:44 AM Subject: Re: [PATCH] mac80211: always use mac80211 loss detection To: Hi Felix, On 6/23/23 12:47, Felix Fietkau wrote: > On 23.06.23 12:29, David Bauer wrote: >> Hi Felix, >> >> On 6/23/23 08:55, Felix Fietkau wrote: >>> On 18.05.23 11:19, David Bauer wrote: >>>> ath10k does not report excessive loss in case of broken block-ack >>>> sessions. The loss is communicated to the host-os, but ath10k does not >>>> trigger a low-ack events by itself. >>>> >>>> The mac80211 framework for loss detection however detects this >>>> circumstance well in case of ath10k. So use it regardless of ath10k's >>>> own loss detection mechanism. >>>> >>>> Signed-off-by: David Bauer >>> >>> Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. >> >> The rationale for removal was in fact to avoid patching ath1xk separately, given these >> are the only drivers using this flag. >> >> I'm aware this is not the nicest approach, do you have any insight if there's a downside >> to always keeping mac80211 loss detection active? >> >> I however still respect the preferation of keeping this limited to specific drivers, I'm >> just interested if there's a deeper rationale / problem i did not spot :) >> >> Just to outline the issue this is trying to avoid - Intel clients started dropping their >> BA sessions sometimes in late 2020 without notifying the AP. The ath10k firmware keeps >> retransmitting exclusive to the device at the lowest rate while not indicating a low-ack >> situation to the host-os, avoiding station kickout. This results in very low throughput >> for all connected stations (aql enabled) up to DoS of the AP (aql disabled). > > My rationale is this: changes to the driver dropping that flag can be upstreamed, because your description implies that it fixes a real bug. > A mac80211 patch turning the flag into an no-op will be rejected, since it doesn't make any sense to keep the flag around. Thanks, I haven't looked at it this way. I will update the patch to account for this. > If it turns out that all ath drivers can't use this flag because of the issue you're describing, we can remove it upstream from mac80211 entirely instead of turning it into a dummy no-op. I was not at the point of upstreaming, as from reading the code the root-cause is within the firmware not reporting low-ack situation. So this requires to be evaluated with all existing platform-firmware in mind. As a sidenote - the issue I'm describing also exists with QCAs own driver, however the ramifications there greatly differ from vendor to vendor. Best David > > - Felix > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel