[PATCH] mac80211: always use mac80211 loss detection

[David Bauer]

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 at 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 at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel