<div dir="ltr">Does the TSQ code honor no-aggregation per voice access class or TCP_NODELAY where the app making the socket write calls knows that the WiFi aggregation isn't likely helpful? Sorry, my Linux stack expertise is quite limited.<br><br>Bob</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 22, 2022 at 12:53 PM Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Neal Cardwell via Bloat <<a href="mailto:bloat@lists.bufferbloat.net" target="_blank">bloat@lists.bufferbloat.net</a>> writes:<br>
<br>
> On Tue, Nov 22, 2022 at 2:43 PM 'Bob McMahon' via BBR Development <<br>
> <a href="mailto:bbr-dev@googlegroups.com" target="_blank">bbr-dev@googlegroups.com</a>> wrote:<br>
><br>
>> Thanks for sharing this. Curious about how the xTSQ value can be set? Can<br>
>> it be done with sysctl?<br>
>><br>
>> *We continue our analysis by using the ms-version of TSQ patch, which<br>
>> enables the tune of the TSQ size allowing each TCP variant to enqueue more<br>
>> than 1 ms of data at the current TCP rate. In particular, we allow to<br>
>> enqueue the equivalent of x ms of data, naming each test xTSQ, with x being<br>
>> an integer value. It is important to notice that this patch has been<br>
>> included in the Linux kernel mainline, and each Wi-Fi driver can now set<br>
>> the desired xTSQ value**.*<br>
>><br>
><br>
> I believe they are setting the xTSQ value using the sk_pacing_shift field,<br>
> which was added here:<br>
><br>
> <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e</a><br>
><br>
> AFAIK the intent is only for drivers to set that, and there's no sysctl for<br>
> that, but of course you could add a sysctl for testing if you wanted.<br>
> :-)<br>
<br>
Yup, indeed this is what mac80211 fiddles with:<br>
<a href="https://elixir.bootlin.com/linux/latest/source/net/mac80211/main.c#L739" rel="noreferrer" target="_blank">https://elixir.bootlin.com/linux/latest/source/net/mac80211/main.c#L739</a><br>
<a href="https://elixir.bootlin.com/linux/latest/source/net/mac80211/tx.c#L4156" rel="noreferrer" target="_blank">https://elixir.bootlin.com/linux/latest/source/net/mac80211/tx.c#L4156</a><br>
<br>
AFAICT, no in-tree drivers override the value set by mac80211.<br>
<br>
I believe the tests in that paper were conducted with this series<br>
applied:<br>
<a href="https://lore.kernel.org/all/20180105113256.14835-1-natale.patriciello@gmail.com/" rel="noreferrer" target="_blank">https://lore.kernel.org/all/20180105113256.14835-1-natale.patriciello@gmail.com/</a><br>
<br>
-Toke<br>
</blockquote></div>

<br>
<span style="background-color:rgb(255,255,255)"><font size="2">This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.</font></span>