From nobody Wed Dec 15 14:43:08 2021 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AE4318EC24F; Wed, 15 Dec 2021 14:43:09 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDdJr6095z3v4r; Wed, 15 Dec 2021 14:43:08 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id AD7131DDB4; Wed, 15 Dec 2021 14:43:08 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 1BFEh8JE064159; Wed, 15 Dec 2021 14:43:08 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 1BFEh8Ts064158; Wed, 15 Dec 2021 14:43:08 GMT (envelope-from git) Date: Wed, 15 Dec 2021 14:43:08 GMT Message-Id: <202112151443.1BFEh8Ts064158@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: Randall Stewart Subject: git: 9b6029653113 - main - tcp: Rack in a rare case we can get stuck sending a very small amount. List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: rrs X-Git-Repository: src X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 9b602965311391f495f4edff246bcb1de5269bbb Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639579388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TriHalykOdpyOHDWe0RsOw6TxXAJqhcQV9DgmIY+rZU=; b=ICzRmpou8kn0cYg+mzqQCfdAYL1umiuEUFnZLbh+hsyLy3K8m22HkXKPWAH8OT8/+yCHbp dnOMB7Be00tzDFjl1u7SUq3KicIl33HaOegq5MhVgB+rtB4JcckUenaFBCyTkJsy9REhja wvlZwxxi9okrJcMPJoE6Qm174x1+BD3kouSL8YjGfpUxr+JUBKZ+9rh5CH56KivtQ9n3u5 ncKVM2MD6EushkLlx61lMpZG0BuySIs4+rMFw6STxsCv2lZg+YAS7xaE4U4xzXKihMTHpg IWTMM/WW6Hvr53lw/hNoC5OlbGOUg1XcVH5Rrxd/7OEN25BOROODZF83DDENGw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639579388; a=rsa-sha256; cv=none; b=Ce5IKWiYiM7mCc1lGVESOMtVLBXRES2lNga2JTKMB+QpreHqOlKvz7/8Cvp8VppTuPfxLd pwQV07xkwiL3E1MikOGrZALpcOJkcB/Vduz4+IFNKkPKseE5qKoLSNxrLW1N0LAtK4MfdP Dkpasbu+7p20+Zu448KLUk+uNqh3jMJYDzHkz0kHxXC528b/4yAR/ATAbreX2RyXrTH2hG 6BTKpp98qeEDcopml1JdU9MvbL6hmuoa3nvmS0f3hXFqX1aMVoukiJ00dvA3TL6y6DIoGb L0xvQPcoHaYjyw/vAyf4X8YdubsJ8RLveSb3sGmaBdXcw4w2Fq2e/q4hOlGZRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by rrs: URL: https://cgit.FreeBSD.org/src/commit/?id=9b602965311391f495f4edff246bcb1de5269bbb commit 9b602965311391f495f4edff246bcb1de5269bbb Author: Randall Stewart AuthorDate: 2021-12-15 14:41:33 +0000 Commit: Randall Stewart CommitDate: 2021-12-15 14:41:33 +0000 tcp: Rack in a rare case we can get stuck sending a very small amount. If a tlp sending new data fails, and then the peer starts talking to us again, we can be in a situation where the tlp_new_data count is set, we are not in recovery and we always send one packet every RTT. The failure has to occur when we send the TLP initially from the ip_output() which is rare. But if it occurs you are basically stuck. This fixes it so we use the new_data count and clear it so we know it will be cleared. If a failure occurs the tlp timer will regenerate a new amount anyway so it is un-needed to carry the value on. Reviewed by: Michael Tuexen Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D33325 --- sys/netinet/tcp_stacks/rack.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/sys/netinet/tcp_stacks/rack.c b/sys/netinet/tcp_stacks/rack.c index 16faa887530f..202829f12b7c 100644 --- a/sys/netinet/tcp_stacks/rack.c +++ b/sys/netinet/tcp_stacks/rack.c @@ -17329,6 +17329,7 @@ again: } else { len = rack->r_ctl.rc_tlp_new_data; } + rack->r_ctl.rc_tlp_new_data = 0; } else { len = rack_what_can_we_send(tp, rack, cwnd_to_use, avail, sb_offset); } @@ -18972,10 +18973,6 @@ out: rack->rc_gp_saw_ss = 1; } } - if (doing_tlp && (rsm == NULL)) { - /* Make sure new data TLP cnt is clear */ - rack->r_ctl.rc_tlp_new_data = 0; - } if (TCPS_HAVEESTABLISHED(tp->t_state) && (tp->t_flags & TF_SACK_PERMIT) && tp->rcv_numsacks > 0)