From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 4/4] tcp: On partial send (incomplete sendmsg()), request a retransmission right away
Date: Thu, 2 Oct 2025 13:00:21 +1000 [thread overview]
Message-ID: <aN3qxZx4VzYBWIBH@zatzit> (raw)
In-Reply-To: <20251002000646.2136202-5-sbrivio@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]
On Thu, Oct 02, 2025 at 02:06:46AM +0200, Stefano Brivio wrote:
> ...possibly with an updated window value. As we're discarding the
> remaining data, we'll need to receive it again. If we don't request
> a retransmission immediately, we'll see an apparent gap in the
> sequence, and request a retransmission on the next data batch or
> segment, but we're just wasting time like that. In packets:
>
> 28686 0.000007 88.198.0.164 → 93.235.151.95 16118 TCP 55414 → 47080 [ACK] Seq=80501 Ack=141 Win=65536 Len=16064 [TCP segment of a reassembled PDU]
> 28687 0.000012 88.198.0.164 → 93.235.151.95 16118 TCP [TCP Window Full] 55414 → 47080 [ACK] Seq=96565 Ack=141 Win=65536 Len=16064 [TCP segment of a reassembled PDU]
>
> on this second data segment, we have a short sendmsg(), and
>
> 28688 0.000026 93.235.151.95 → 88.198.0.164 54 TCP 47080 → 55414 [ACK] Seq=141 Ack=90721 Win=32128 Len=0
>
> consequently acknowledge it, without requesting a retransmission,
>
> 28689 0.000006 88.198.0.164 → 93.235.151.95 8866 HTTP HTTP/1.1 200 ok (text/css)
>
> so the server proceeds sending a bit more, but
>
> 28690 0.000016 93.235.151.95 → 88.198.0.164 54 TCP [TCP Dup ACK 28688#1] 47080 → 55414 [ACK] Seq=141 Ack=90721 Win=32128 Len=0
> 28691 0.000000 93.235.151.95 → 88.198.0.164 54 TCP [TCP Dup ACK 28688#2] 47080 → 55414 [ACK] Seq=141 Ack=90721 Win=32128 Len=0
>
> we'll throw that data (from frame #28689) away, and finally request
> a retransmission as we spotted the gap now.
>
> Request a retransmission as soon as we know we'll need it, instead.
>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tcp.c b/tcp.c
> index 5a7a607..ae5e7a1 100644
> --- a/tcp.c
> +++ b/tcp.c
> @@ -1876,7 +1876,7 @@ eintr:
> }
>
> out:
> - if (keep != -1) {
> + if (keep != -1 || partial_send) {
> /* We use an 8-bit approximation here: the associated risk is
> * that we skip a duplicate ACK on 8-bit sequence number
> * collision. Fast retransmit is a SHOULD in RFC 5681, 3.2.
> --
> 2.43.0
>
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2025-10-02 3:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 0:06 [PATCH 0/4] tcp: Fix bad switch to CLOSE-WAIT state and surrounding issues Stefano Brivio
2025-10-02 0:06 ` [PATCH 1/4] tcp: Fix ACK sequence on FIN to tap Stefano Brivio
2025-10-02 2:41 ` David Gibson
2025-10-02 11:58 ` Stefano Brivio
2025-10-03 3:19 ` David Gibson
2025-10-06 22:32 ` Stefano Brivio
2025-10-06 23:31 ` David Gibson
2025-10-02 0:06 ` [PATCH 2/4] tcp: Completely ignore data segment in CLOSE-WAIT state, log a message Stefano Brivio
2025-10-02 2:44 ` David Gibson
2025-10-02 0:06 ` [PATCH 3/4] tcp: Don't consider FIN flags with mismatching sequence Stefano Brivio
2025-10-02 2:52 ` David Gibson
2025-10-02 3:02 ` David Gibson
2025-10-02 11:51 ` Stefano Brivio
2025-10-03 3:43 ` David Gibson
2025-10-06 22:32 ` Stefano Brivio
2025-10-06 23:34 ` David Gibson
2025-10-02 0:06 ` [PATCH 4/4] tcp: On partial send (incomplete sendmsg()), request a retransmission right away Stefano Brivio
2025-10-02 3:00 ` David Gibson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aN3qxZx4VzYBWIBH@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).