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