From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4A6A2D46B3 for ; Mon, 3 Aug 2026 08:18:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785745102; cv=none; b=deCXO9o/WhuaXT7thFXvPDiOPhtOUsyAxElnXQ0FEyVbxPw5DCXpYqWEbQVeoqZZBcKRm82yb4sGhdkVvfUX5EGxyP+5AuL63RkP2zfmt6Wfrqp+RvLhx7bx5EQTpcl5P+EbnK7vmYTWC1wcWbQBUEHPCHSv5UmA8t6+7Y0dQlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785745102; c=relaxed/simple; bh=l51BPZrmcVPmY1ZAOvafMoj/ozAT+EEV4unz04OI394=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=j8GycgvTCwowc3NOhY7gqpBbGQn14uxXFY8MXCjDMeVr4177ATacg51cajak+U3rReQBGlPOsNE7fvyxDVckHHnWOFeIhdYk0Se60SH7RLRyy9MBKTjeLdYpYEc4MWBuQB9dJISRbdAf6M8+cciwrQ5QO151uDI7fjGbLH9QNms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DZrfsmdf; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=FJ2Rqpuv; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DZrfsmdf"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="FJ2Rqpuv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785745099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k8iKikqFO3zEFEsq/VazzrCGyVxKknjb3/NN6IXkpV4=; b=DZrfsmdff7dUo+/Qr30cUo0ZH9n+zRMdE0haJU7EHyxyXBRwbes9svkqtVPFxZ9P637EKY o3EcShD3QZg6o22ERkacehbp/VhPJPHOHLguY/ks0x5yKCf4P5U9qIAmZpYQea15N6dPWf zkdNkozR9iHpdZJFUXK/wAUk4n72Ek0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-301-idG9DprLN-iItd5IepfFJA-1; Mon, 03 Aug 2026 04:18:16 -0400 X-MC-Unique: idG9DprLN-iItd5IepfFJA-1 X-Mimecast-MFC-AGG-ID: idG9DprLN-iItd5IepfFJA_1785745095 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-495495ad5ddso7824935e9.3 for ; Mon, 03 Aug 2026 01:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785745095; x=1786349895; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=k8iKikqFO3zEFEsq/VazzrCGyVxKknjb3/NN6IXkpV4=; b=FJ2RqpuvflL1PblY6ZtQrdAEa5hnZxBYvhZ//MYhs2dFOozNJ2lum79DQzHuF3put/ NWtmDsKZRTqyFA/dIMAD0dWet/FBbbO8nyEWbhgSyftrHi5uIAlnR+Vk8tNQmc1lIWc3 qauccbsss0pznHFBH2Nhv+gZGAae0gcVE9aadIODU0z34Vqo28Q5JeSeIygvxOOIE4BB u/itACFCt/nxKhVNCi1LS1fnNBqB3oWkwDfQ221dCrpmBX14u6HeIvtM2hzSwa3l6tXw eFQjVxbXwP5N3CONZIpgWT94wvOulWfCJ34vZ0xQJljja/Q8nYcPcD59wQS7VPzWAdO/ orQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785745095; x=1786349895; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=k8iKikqFO3zEFEsq/VazzrCGyVxKknjb3/NN6IXkpV4=; b=Tu9Zf44VT8JiKgMlBeCu44Hei1sddpwpTO0UObG4ND8gqE3TzOjPAVE1qn9qMGCzjm ZirbFhgaPAWs5b3rIhJUXtnBDaFXctTTx7BHQkD5W2nJRaLV5m8TFHguONMDadFT3muy 9mHECq8y7ruy5E+6QlIaSshMkc8Z7KnbxhQOIyz4RPsOseNFvivYKyV816Qd5klPNEsU IBGxmy0WnWQqh9RKEPXAj5Nl+mY6RmnX24V3R9bAgQg/VeTL78p5HpkL8gDfKTaaAzgI siJP5mI81CboMLO3l5jN+SVeKfVgvIpzGESu4lfr4SLUi5lZlJqN4SB5yWgpj+8t55J9 ZsmA== X-Forwarded-Encrypted: i=1; AHgh+RocRBNJZSbTHP+X6vqiVlFIajGQw8PucE8gXRaAPyEmfNYTG49GKKi7h1f9rY7eaV3FaPwHJluW9TKP8xk=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1BK4VGM1DGbLzY9QClsQTD8K/jItak2KIcsCv1hzPQlwkuMj2 vVJB92SgfXG7j2Z6EY6lmXcLmMntvgbrsrIhZERmlZjpUcw7dXv5rnVPAVj5r6C//ET7XKtd58c GcRlmzfcnBqalzlD12M79UnOQcqpSzatK4N+82nSUkR/qr6ooaTY6SOSNiC+PQ3pdYA== X-Gm-Gg: AR+sD13H75z4WcLTBQZysuNmoHRwngTrjy+GR3JI9sW3Rz15ADIQNWiri5WBdvW3sCG IMjvHsJC98N7BwNz7QZdJwOwMODodlJ0K67yQrnyMQTmFstd8WubULWyQrMJcxdMHeQo8Ta2NSD vUDbEbV4tqpxc1wqxPBRkzi9s3HQZKrsvJlgXKTS7i5835AHazW6wO3Ar5A63qjOJzzXqj54LXy vgNWlVGweX/LudCwkLtDsTKVcvqFG5rzdD+q34RweKpwkc+Brq+dyOnKUMDovojb1bgW+nQQW9+ NDRRKwW2rG9bSk3d5DxedR49ojouQVeeGs3CkN/nzgc2rS8APn3Ar73mClCRhQyq1ZgmoO2Ahhx autsxn2ZZCt6duwzWXrgAakxv6XjLeYqLzit/tb/MVBtKczlaFDKwPzC6MZMKSTUhwLT4xTASEU k= X-Received: by 2002:a05:600c:2294:b0:492:4e09:9fc1 with SMTP id 5b1f17b1804b1-4980c67af97mr160439495e9.15.1785745095506; Mon, 03 Aug 2026 01:18:15 -0700 (PDT) X-Received: by 2002:a05:600c:2294:b0:492:4e09:9fc1 with SMTP id 5b1f17b1804b1-4980c67af97mr160438935e9.15.1785745095069; Mon, 03 Aug 2026 01:18:15 -0700 (PDT) Received: from [192.168.188.217] (ip239-44-231-195.pool-bba.aruba.it. [195.231.44.239]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49807b5f0adsm202152355e9.4.2026.08.03.01.18.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Aug 2026 01:18:14 -0700 (PDT) Message-ID: <3b7ee98e-cdaa-4c53-b6d2-a1d4e1bab8e0@redhat.com> Date: Mon, 3 Aug 2026 10:18:13 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss() From: Paolo Abeni To: Jakub Kicinski , Nathan Gao , Kuniyuki Iwashima Cc: Eric Dumazet , Neal Cardwell , "David S . Miller" , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260725030806.28135-1-zcgao@amazon.com> <20260731174644.02410e2d@kernel.org> <74f99014-d09e-46ca-9c02-d10570f62fe1@redhat.com> Content-Language: en-US In-Reply-To: <74f99014-d09e-46ca-9c02-d10570f62fe1@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/3/26 10:09 AM, Paolo Abeni wrote: > On 8/1/26 2:46 AM, Jakub Kicinski wrote: >> On Fri, 24 Jul 2026 20:08:06 -0700 Nathan Gao wrote: >>> Commit f5da7c45188e ("tcp: adjust rcvq_space after updating scaling >>> ratio") replaced the direct window_clamp update in tcp_measure_rcv_mss() >>> with a call to tcp_set_window_clamp(), a helper that implements the >>> TCP_WINDOW_CLAMP setsockopt. As a side effect, the helper also shrinks >>> rcv_ssthresh via __tcp_adjust_rcv_ssthresh(). >>> >>> As a result, each scaling_ratio decrease detected by >>> tcp_measure_rcv_mss() also cuts rcv_ssthresh. Elsewhere in TCP, >>> rcv_ssthresh is usually cut under memory pressure and grows via >>> tcp_grow_window(). >>> >>> Flows whose segment sizes vary keep scaling_ratio oscillating, which >>> leads to an unstable rcv_ssthresh: a dip of rcv_ssthresh only recovers >>> via tcp_grow_window(), keeping the advertised window at a relatively >>> low level even after the ratio itself has recovered, and can even stall >>> the sender. >>> >>> Observed on a customer's proxy gateway after upgrading from kernel 6.1 >>> to 6.12: in the worst case, rcv_ssthresh was cut in half by a >>> scaling_ratio dip. P99 latency jumped from <10ms on 6.1 to ~100ms on >>> 6.12, and almost returned to the 6.1 level with this patch applied. >>> >>> Restore the plain WRITE_ONCE() update of window_clamp, as introduced >>> in commit a2cbb1603943 ("tcp: Update window clamping condition"), and >>> keep the rcvq_space.space adjustment. Now rcv_ssthresh is decoupled from >>> scaling_ratio changes in tcp_measure_rcv_mss(). >>> >>> Fixes: f5da7c45188e ("tcp: adjust rcvq_space after updating scaling ratio") >>> Signed-off-by: Nathan Gao >> >> Not sure, I mean regression is a regression, but also the previous >> behavior seems to have just been lucky rather than correct in principle? >> >> Looks like Eric and Neal are AFK, Kuniyuki, Paolo, any opinion on this >> patch? > A quick grep confirm that except for f5da7c45188e, only the control path > calls tcp_set_window_clamp(), which IMHO supports this patch rationale. > My understanding is also that this patch should not re-introduce the > issue addressed by the blamed commit. > > It would be great to have a pktdrill tests for at least one of the 2 > relevant scenarios (the one described here and the one relevant for > f5da7c45188e). My totally uneducated impression is that writing a packet > drill for the case described here should be slightly less difficult than > the other option, as there is no MTU dependency. > > TL;DR: I *think* this patch make sense, pktdrill would be helpful but > not a blocker. Uhm... Above I did not take in account how far we are in the current release cycle. The issue has been unnoticed for a considerable amount of time, and the chances the fix would introduce some other regressions are not 0, so I think this patch would deserve at least another positive review to be merged now. Thanks, Paolo