[Make-wifi-fast] Fwd: [PATCH] mac80211: always use mac80211 loss detection

[Make-wifi-fast] Fwd: [PATCH] mac80211: always use mac80211 loss detection

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

---------- Forwarded message ---------
From: David Bauer <mail@david-bauer.net>
Date: Fri, Jun 23, 2023, 5:44 AM
Subject: Re: [PATCH] mac80211: always use mac80211 loss detection
To: <openwrt-devel@lists.openwrt.org>


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 <mail@david-bauer.net>
>>>
>>> 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

[-- Attachment #2: Type: text/html, Size: 4537 bytes --]