Re: [Make-wifi-fast] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

["Muhammad Ahsan" <muhammadahsan@umt.edu.pk>]

[-- Attachment #1.1: Type: text/plain, Size: 5854 bytes --]

Hi dev group guys,

 

I need to use sysctl to set ms value for net.ipv4.tcp_limit_output_ms .

 

The TSQ patch attached is not working or letting me do that . I am on linux 5.13.12 

Manually changing tx_sk_pacing_shift <https://elixir.bootlin.com/linux/latest/C/ident/tx_sk_pacing_shift>  = 7;  variable in main.c  needs to recompile kernel everytime…

 

I need to have sysctl to control the ms value , to set  2TSQ,4TSQ,8TSQ  etc for my wifi chipset.

 

I will be thankful if anyone can help me in it. 

 

 

Rgds,

Ahsan

 

 

 

From: 'Neal Cardwell' via BBR Development <bbr-dev@googlegroups.com> 
Sent: Wednesday, November 23, 2022 1:10 AM
To: Bob McMahon <bob.mcmahon@broadcom.com>
Cc: Dave Taht <dave.taht@gmail.com>; Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>; bloat <bloat@lists.bufferbloat.net>; BBR Development <bbr-dev@googlegroups.com>
Subject: Re: [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

 

On Tue, Nov 22, 2022 at 2:43 PM 'Bob McMahon' via BBR Development <bbr-dev@googlegroups.com <mailto:bbr-dev@googlegroups.com> > wrote:

Thanks for sharing this. Curious about how the xTSQ value can be set? Can it be done with sysctl?

We continue our analysis by using the ms-version of TSQ patch, which enables the tune of the TSQ size allowing each TCP variant to enqueue more than 1 ms of data at the current TCP rate. In particular, we allow to enqueue the equivalent of x ms of data, naming each test xTSQ, with x being an integer value. It is important to notice that this patch has been included in the Linux kernel mainline, and each Wi-Fi driver can now set the desired xTSQ value.

 

I believe they are setting the xTSQ value using the sk_pacing_shift field, which was added here:

   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e

 

AFAIK the intent is only for drivers to set that, and there's no sysctl for that, but of course you could add a sysctl for testing if you wanted. :-)

 

cheers,

neal

 

 

 

Another thing that could be interesting is the WiFi aggregation stop reasons, e.g. how many times agg stopped per hitting the max mpdu per ampdu vs the software fifo going empty (i.e. no more packets available to the driver from the TCP stack) per that TXOP.

Finally, many (most?) APs are forwarding and feeding packets at at the hardware level so not sure that the linux stack matters as much for an AP based analysis, particularly when considering multi user transmissions, i.e. multiple WiFi clients are active and sharing TXOPs.

Bob

On Mon, Nov 21, 2022 at 10:04 PM Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com> > wrote:

This paper came out last month. Good work, really exhaustive look at
two chipsets, multiple congestion controls and the interactions with
TSQ, with
lots and lots of flent.

https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9772053

as for wifi6... don't make me start talking about wifi6... but some of
these tests look like a good baseline to start comparing the ath11k,
mt79, etc..

Paper kind of misses the negative impact of AQL in the ath10k (and
most likely also the mt76 and mt79 chips)

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC

-- 
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+unsubscribe@googlegroups.com <mailto:bbr-dev%2Bunsubscribe@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAA93jw6yJU10wh9ajqX4yW2AvnJPStyWAAcV4%2BoQ8wSGsJgKZA%40mail.gmail.com.


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. 

-- 
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+unsubscribe@googlegroups.com <mailto:bbr-dev+unsubscribe@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAHb6LvrK_exkt_rbukYkF4_hwPXyy9T%2BZNGzdK79x91RrK49Mg%40mail.gmail.com <https://groups.google.com/d/msgid/bbr-dev/CAHb6LvrK_exkt_rbukYkF4_hwPXyy9T%2BZNGzdK79x91RrK49Mg%40mail.gmail.com?utm_medium=email&utm_source=footer> .

-- 
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+unsubscribe@googlegroups.com <mailto:bbr-dev+unsubscribe@googlegroups.com> .
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CADVnQyn9OSxPcF2JsUHdiWLTvAAdN5vs1uyiRBL0AS8yH8niYw%40mail.gmail.com <https://groups.google.com/d/msgid/bbr-dev/CADVnQyn9OSxPcF2JsUHdiWLTvAAdN5vs1uyiRBL0AS8yH8niYw%40mail.gmail.com?utm_medium=email&utm_source=footer> .


[-- Attachment #1.2: Type: text/html, Size: 10598 bytes --]

[-- Attachment #2: TSQ.patch --]
[-- Type: application/octet-stream, Size: 4787 bytes --]

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 974ab47ae53a..be3eae47b2e7 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -723,8 +723,30 @@ tcp_limit_output_bytes - INTEGER
 	typical pfifo_fast qdiscs.
 	tcp_limit_output_bytes limits the number of bytes on qdisc
 	or device to reduce artificial RTT/cwnd and reduce bufferbloat.
+	The overall limit is given by the following (rate is in B/ms):
+	limit = min(output_bytes, max(output_pkt * mss, output_ms * rate)
+	Set to -1 to unconditionally disable TSQ, regardless of the
+	values of tcp_limit_output_ms and tcp_limit_output_pkt.
 	Default: 262144
 
+tcp_limit_output_ms - UNSIGNED INTEGER
+	Controls TCP Small Queue limit per TCP socket, under a time point
+	of view. Given a transmission rate, limit the bytes on qdisc or
+	device to a value that can be transmitted approximately in the
+	time provided in this parameter at the given rate. This limit
+	is doubled for retransmissions. The overall limit is given by
+	the following (rate is in B/ms):
+	limit = min(output_bytes, max(output_pkt * mss, output_ms * rate)
+	Default: 1
+
+tcp_limit_output_pkt - UNSIGNED INTEGER
+	Controls TCP Small Queue limit per tcp socket.
+	tcp_limit_output_pkt limits the number of packets queued in
+	qdisc/device. This limit is doubled for retransmissions.
+	The overall limit is given by the following (rate is in B/ms):
+	limit = min(output_bytes, max(output_pkt * mss, output_ms * rate)
+	Default: 2
+
 tcp_challenge_ack_limit - INTEGER
 	Limits number of Challenge ACK sent per second, as recommended
 	in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index e25bfdf78c2e..f06fc0c2ecdc 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -725,6 +725,9 @@ static int __ath_regd_init(struct ath_regulatory *reg)
 			       regdmn);
 		}
 	}
+  country = ath_regd_find_country(CTRY_ITALY);
+  printk(KERN_DEBUG
+      "ath: fixing country to 0x%0x\n", CTRY_ITALY);
 
 	reg->regpair = ath_get_regpair(regdmn);
 
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 48978125947b..99edd69d9338 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -270,6 +270,8 @@ extern int sysctl_tcp_recovery;
 #define TCP_RACK_LOSS_DETECTION  0x1 /* Use RACK to detect losses */
 
 extern int sysctl_tcp_limit_output_bytes;
+extern unsigned int sysctl_tcp_limit_output_ms;
+extern unsigned int sysctl_tcp_limit_output_pkt;
 extern int sysctl_tcp_challenge_ack_limit;
 extern int sysctl_tcp_min_tso_segs;
 extern int sysctl_tcp_min_rtt_wlen;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 9bf809726066..0e7f27596a20 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -589,6 +589,20 @@ static struct ctl_table ipv4_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec
 	},
+	{
+		.procname	= "tcp_limit_output_ms",
+		.data		= &sysctl_tcp_limit_output_ms,
+		.maxlen		= sizeof(unsigned int),
+		.mode		= 0644,
+		.proc_handler	= proc_douintvec
+	},
+	{
+		.procname	= "tcp_limit_output_pkt",
+		.data		= &sysctl_tcp_limit_output_pkt,
+		.maxlen		= sizeof(unsigned int),
+		.mode		= 0644,
+		.proc_handler	= proc_douintvec
+	},
 	{
 		.procname	= "tcp_challenge_ack_limit",
 		.data		= &sysctl_tcp_challenge_ack_limit,
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 40f7c8ee9ba6..d06f1ae6950d 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -53,6 +53,12 @@ int sysctl_tcp_workaround_signed_windows __read_mostly = 0;
 /* Default TSQ limit of four TSO segments */
 int sysctl_tcp_limit_output_bytes __read_mostly = 262144;
 
+/* Default TSQ limit of 1 ms of data, if the rate is set */
+unsigned int sysctl_tcp_limit_output_ms __read_mostly = 1;
+
+/* Default TSQ limit of 2 packets */
+unsigned int sysctl_tcp_limit_output_pkt __read_mostly = 2;
+
 /* This limits the percentage of the congestion window which we
  * will allow a single TSO frame to consume.  Building TSO frames
  * which are too large can cause TCP streams to be bursty.
@@ -2176,7 +2182,11 @@ static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
 {
 	unsigned int limit;
 
-	limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+	if (sysctl_tcp_limit_output_bytes < 0)
+		return false;
+
+	limit = sysctl_tcp_limit_output_ms * (sk->sk_pacing_rate >> 10);
+	limit = max(sysctl_tcp_limit_output_pkt * skb->truesize, limit);
 	limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
 	limit <<= factor;