Thread (30 messages) 30 messages, 3 authors, 2026-02-05

Re: [net-next,v9,09/15] quic: add congestion control

From: Xin Long <lucien.xin@gmail.com>
Date: 2026-02-05 19:00:46
Also in: linux-cifs

On Thu, Feb 5, 2026 at 6:55 AM Simon Horman [off-list ref] wrote:
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
quic: add congestion control

This patch introduces quic_cong for RTT measurement and congestion control,
implementing a state machine with slow start, congestion avoidance, and
recovery phases using the New Reno algorithm.
quoted
diff --git a/net/quic/cong.c b/net/quic/cong.c
--- /dev/null
+++ b/net/quic/cong.c
[ ... ]
quoted
+static int quic_cong_check_persistent_congestion(struct quic_cong *cong, u64 time)
+{
+     u32 ssthresh;
+
+     /* rfc9002#section-7.6.1:
+      *   (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
+      *      kPersistentCongestionThreshold
+      */
+     ssthresh = cong->smoothed_rtt + max(4 * cong->rttvar, QUIC_KGRANULARITY);
+     ssthresh = (ssthresh + cong->max_ack_delay) * QUIC_KPERSISTENT_CONGESTION_THRESHOLD;
+     if (cong->time - time <= ssthresh)
+             return 0;
[ ... ]
quoted
+/* rfc9002#section-5: Estimating the Round-Trip Time */
+void quic_cong_rtt_update(struct quic_cong *cong, u64 time, u32 ack_delay)
+{
+     u32 adjusted_rtt, rttvar_sample;
+
+     /* Ignore RTT sample if ACK delay is suspiciously large. */
+     if (ack_delay > cong->max_ack_delay * 2)
+             return;
+
+     /* rfc9002#section-5.1: latest_rtt = ack_time - send_time_of_largest_acked */
+     cong->latest_rtt = cong->time - time;
The field cong->time is described as "Cached current timestamp" in struct
quic_cong, but where is it written? The socket struct is zero-initialized,
so cong->time will always be 0.

When computing RTT with a positive packet send timestamp in the time
parameter, does this cause unsigned integer underflow? For example, if the
packet was sent at time 12345, computing 0 - 12345 wraps to a very large
value.

The same issue appears in quic_cong_check_persistent_congestion() where
cong->time - time is compared against ssthresh, and in quic_reno_on_packet_lost()
and quic_reno_on_process_ecn() where recovery_time is set to cong->time.
This is not a problem, cong->time will always be set before processing
the packet on the TX path in the next patch series.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help