6.12-stable patches

added patches:
	net_sched-sch_fq-don-t-follow-the-fast-path-if-tx-is-behind-now.patch

diff --git a/queue-6.12/net_sched-sch_fq-don-t-follow-the-fast-path-if-tx-is-behind-now.patch b/queue-6.12/net_sched-sch_fq-don-t-follow-the-fast-path-if-tx-is-behind-now.patch
new file mode 100644 (file)
index 0000000..d7ddf28
--- /dev/null
+++ b/queue-6.12/net_sched-sch_fq-don-t-follow-the-fast-path-if-tx-is-behind-now.patch
@@ -0,0 +1,75 @@
+From 122aba8c80618eca904490b1733af27fb8f07528 Mon Sep 17 00:00:00 2001
+From: Jakub Kicinski <kuba@kernel.org>
+Date: Sat, 23 Nov 2024 18:21:48 -0800
+Subject: net_sched: sch_fq: don't follow the fast path if Tx is behind now
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+commit 122aba8c80618eca904490b1733af27fb8f07528 upstream.
+
+Recent kernels cause a lot of TCP retransmissions
+
+[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
+[  5]   0.00-1.00   sec  2.24 GBytes  19.2 Gbits/sec  2767    442 KBytes
+[  5]   1.00-2.00   sec  2.23 GBytes  19.1 Gbits/sec  2312    350 KBytes
+                                                      ^^^^
+
+Replacing the qdisc with pfifo makes retransmissions go away.
+
+It appears that a flow may have a delayed packet with a very near
+Tx time. Later, we may get busy processing Rx and the target Tx time
+will pass, but we won't service Tx since the CPU is busy with Rx.
+If Rx sees an ACK and we try to push more data for the delayed flow
+we may fastpath the skb, not realizing that there are already "ready
+to send" packets for this flow sitting in the qdisc.
+
+Don't trust the fastpath if we are "behind" according to the projected
+Tx time for next flow waiting in the Qdisc. Because we consider anything
+within the offload window to be okay for fastpath we must consider
+the entire offload window as "now".
+
+Qdisc config:
+
+qdisc fq 8001: dev eth0 parent 1234:1 limit 10000p flow_limit 100p \
+  buckets 32768 orphan_mask 1023 bands 3 \
+  priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 \
+  weights 589824 196608 65536 quantum 3028b initial_quantum 15140b \
+  low_rate_threshold 550Kbit \
+  refill_delay 40ms timer_slack 10us horizon 10s horizon_drop
+
+For iperf this change seems to do fine, the reordering is gone.
+The fastpath still gets used most of the time:
+
+  gc 0 highprio 0 fastpath 142614 throttled 418309 latency 19.1us
+   xx_behind 2731
+
+where "xx_behind" counts how many times we hit the new "return false".
+
+CC: stable@vger.kernel.org
+Fixes: 076433bd78d7 ("net_sched: sch_fq: add fast path for mostly idle qdisc")
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://patch.msgid.link/20241124022148.3126719-1-kuba@kernel.org
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+[stable: drop the offload horizon, it's not supported / 0]
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/sch_fq.c |    6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/net/sched/sch_fq.c
++++ b/net/sched/sch_fq.c
+@@ -331,6 +331,12 @@ static bool fq_fastpath_check(const stru
+                */
+               if (q->internal.qlen >= 8)
+                       return false;
++
++              /* Ordering invariants fall apart if some delayed flows
++               * are ready but we haven't serviced them, yet.
++               */
++              if (q->time_next_delayed_flow <= now)
++                      return false;
+       }
+ 
+       sk = skb->sk;

diff --git a/queue-6.12/series b/queue-6.12/series
index 18d6c01eb3078050d79e22cc6ba8772afdcd7ce2..a77ab62b9b357eabc23da90e391d0c7dd9d0a457 100644 (file)
--- a/queue-6.12/series
+++ b/queue-6.12/series
@@ -621,3 +621,4 @@ asoc-amd-yc-fix-for-enabling-dmic-on-acp6x-via-_dsd-.patch
 asoc-mediatek-check-num_codecs-is-not-zero-to-avoid-.patch
 s390-pci-fix-potential-double-remove-of-hotplug-slot.patch
 f2fs-fix-fiemap-failure-issue-when-page-size-is-16kb.patch
+net_sched-sch_fq-don-t-follow-the-fast-path-if-tx-is-behind-now.patch