From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 597A73CB37 for ; Fri, 23 Jun 2023 08:55:54 -0400 (EDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1b51414b080so3182505ad.0 for ; Fri, 23 Jun 2023 05:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687524953; x=1690116953; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=SbulMKd1tmCYj4z2+e9UPnPd8t2Ecu1u8Epko3Ns6DY=; b=kQPrKdIBulypLkru/Y8BuBe3VuLBl9b5SRXkwTTef2Svk/01pDzbU1lZCYh0T1qrrK kWE7XJw4riwmYmX71Z/jlSC1B2E6Qf6R+P4K/aoSMd7cJHKZBs8WAIgIKs7Bjj3XWJdk DMPYzzX2LqcLzTahr2De4aTrFdj1+IAWGWp13ag+aKU60a3I6LBKdmVtNastbu4qrCST IPf0falDAzMrML/jm3G5Mt3K5W+hpLpgKKREFZ5YbTTUhnqDqcL6JVKooXtHiWHSHzTT vEUXdnKnJQnVYcJKzkGnpQsBBaxizkigv2tvCuz1aYwln10VL8mxGDqasKGzVYPRCnNw 3fEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687524953; x=1690116953; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SbulMKd1tmCYj4z2+e9UPnPd8t2Ecu1u8Epko3Ns6DY=; b=FyevH4yRgRp4PDiM2NLkiQzPYqac5z5VEYjPtHQHO4RZ6UabafGNp3hu3DfYRJn/gI Ix+Ff0RM4fk9wnQLNXvgChFSv67492N9G4Vj857tJ7z0KKllKQow2pwBhAHkw1f2xA/G xGduez8kydmLJlvQ1/1xBqJ3EDIfsksohrLWLH9vfSayGj60XW1o3icM8/4TO0i+g+vL LxFROGlA84CFsXjTgTxa4/b3mXraPXcrCuIQEQvwMeeM5eonuZ/753C6bcw4T1HW/NFl jptCGOy+m0WulUeeQM0455n5Q6o/ZfMmFbTE1CGXa5GnL5G0KVFXCk0a/wKru7PaR6OC MhVA== X-Gm-Message-State: AC+VfDycSyMFLq1nlsMzSrfFjLchlXQHLl8JD/oZRRHxyV7lgFZfodru K5SUHi2DT4ihCp12Slcjj1CtMQG/G3N4j29SUbQ79GgjlCs= X-Google-Smtp-Source: ACHHUZ7ucXw+2u0P1zKxG2x7Hv0wYyWKmaAco58TXP81YgRNr9yJnhPvnO6nU9J44+DDHppFWw3Sp4nY1ht3MSG64zM= X-Received: by 2002:a17:902:d48b:b0:1b5:642e:139d with SMTP id c11-20020a170902d48b00b001b5642e139dmr15822027plg.10.1687524952750; Fri, 23 Jun 2023 05:55:52 -0700 (PDT) MIME-Version: 1.0 References: <20230518091912.181090-1-mail@david-bauer.net> <909f5840-96d1-00c2-c942-68e42a7c8cf9@david-bauer.net> In-Reply-To: From: Dave Taht Date: Fri, 23 Jun 2023 06:55:41 -0600 Message-ID: To: Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000005bc67205fecb85a2" Subject: [Make-wifi-fast] Fwd: [PATCH] mac80211: always use mac80211 loss detection X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2023 12:55:54 -0000 --0000000000005bc67205fecb85a2 Content-Type: text/plain; charset="UTF-8" ---------- 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 --0000000000005bc67205fecb85a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ---------
From: David Bauer <mail@david-bauer.net>= ;
Date: Fri, Jun 23, 2023, 5:44 AM
Subject: Re: [PATCH] mac802= 11: 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 bl= ock-ack
>>>> sessions. The loss is communicated to the host-os, but ath= 10k 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&= gt;
>>>
>>> Please make a patch for ath10k instead of turning the flag int= o a no-op in mac80211.
>>
>> The rationale for removal was in fact to avoid patching ath1xk sep= arately, given these
>> are the only drivers using this flag.
>>
>> I'm aware this is not the nicest approach, do you have any ins= ight 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 a= th10k firmware keeps
>> retransmitting exclusive to the device at the lowest rate while no= t indicating a low-ack
>> situation to the host-os, avoiding station kickout. This results i= n 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, sinc= e 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 acc= ount for this.

> If it turns out that all ath drivers can't use this flag because o= f 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-ca= use is within
the firmware not reporting low-ack situation. So this requires to be evalua= ted with all
existing platform-firmware in mind.

As a sidenote - the issue I'm describing also exists with QCAs own driv= er, 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/ma= ilman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman= /listinfo/openwrt-devel
--0000000000005bc67205fecb85a2--