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]) by passt.top (Postfix) with ESMTP id CED575A004E for ; Thu, 13 Jun 2024 12:50:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718275833; 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=JwiZ7KW02VwdF+6XOtW/Wr/4az/01WFF0KNX0AYwDl0=; b=ZHo2kJJEDNkhax/MXrFR66Wlfrh02yEcZnfwiGHr1o7RJLBb/FBsnfkZsoFKN4mn25uABA pyCQA3nYpc4frejWX1w0m2UXggYQZqYuPfCV21eTwjgohpqDtwx5TM5yiqaNupSmDdwES2 kRqkJnAXE1330gAhJMG276cQ03pzRwg= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-421-2jz8iVGcOW-jZS0EU0xt9w-1; Thu, 13 Jun 2024 06:50:32 -0400 X-MC-Unique: 2jz8iVGcOW-jZS0EU0xt9w-1 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-795bb25ae28so309969385a.0 for ; Thu, 13 Jun 2024 03:50:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718275831; x=1718880631; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=JwiZ7KW02VwdF+6XOtW/Wr/4az/01WFF0KNX0AYwDl0=; b=tPVUMj2pVyzMvwNqjqW9eiBczoGQEiX1rW2tJcalZrianQQP1p0Bv55IqJQt+IjL1D YyEClYNlyCkd5QUHKrAvZ+RU8EKTaA86r+08KApzWxyT7TlymaLHP4pUC5iumBSAzgQ7 5YRX6qsJoArNukFO62yq+q/Ova9hUeH/66UxGco1NuY0bCZUSi/6jFTaXe+a43lWJV6p Wg3HhwDSFjE1uTYjJobWVlUw5+B5MQi5kpRjImQoOztODgowd3bGlbQSsGjvKB9KkMgN ExLlYLqpWJIqNSR4lHhEf47Di11vGa6FzPVEZ5L++0gX/5QkCZBW/7ptCIuYCg+wcAiX rVXQ== X-Gm-Message-State: AOJu0YyoyNV003RgT427IAaNBmFrb0NcY9IOb0w9XWR1TOgvnb/Z6L4Q PSJQvnVASoLMg03dXgoF2I3iYoLnBXa3VkPbCS6ZskqnPc8S0/EHoTv6KdjOQ+AC9i37S5FKJkA ymKk8HgFoR9t0w0ooNAvVXx2UeDvOMqUzE3qvHDJYDKNLek/qJ6S2d+Yo4TX8 X-Received: by 2002:a05:620a:1924:b0:795:484a:7f05 with SMTP id af79cd13be357-798100dd012mr344133585a.1.1718275831372; Thu, 13 Jun 2024 03:50:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHaHUvyYJcZUdyJtAGhd1mVl7relj6pVq9HmtTvgJmeWoM6wJZSsW613Uh+mYxlFc2p3EvqZg== X-Received: by 2002:a05:620a:1924:b0:795:484a:7f05 with SMTP id af79cd13be357-798100dd012mr344130585a.1.1718275830799; Thu, 13 Jun 2024 03:50:30 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id af79cd13be357-798aaee575fsm41436485a.40.2024.06.13.03.50.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2024 03:50:30 -0700 (PDT) Date: Thu, 13 Jun 2024 12:49:54 +0200 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v6 1/8] tcp: extract buffer management from tcp_send_flag() Message-ID: <20240613124954.0134e128@elisabeth> In-Reply-To: <79e33c3e-1194-4acb-b1ab-71d1ac6d94a7@redhat.com> References: <20240612154734.1044883-1-lvivier@redhat.com> <20240612154734.1044883-2-lvivier@redhat.com> <20240612232210.3b1f975f@elisabeth> <20240613080719.67933d22@elisabeth> <20240613121415.4c92b62e@elisabeth> <79e33c3e-1194-4acb-b1ab-71d1ac6d94a7@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 54N3F7NTWSHQJZLCCM2Q6E4AQULFXLCG X-Message-ID-Hash: 54N3F7NTWSHQJZLCCM2Q6E4AQULFXLCG X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 13 Jun 2024 12:22:54 +0200 Laurent Vivier wrote: > On 13/06/2024 12:14, Stefano Brivio wrote: > > On Thu, 13 Jun 2024 10:24:11 +0200 > > Laurent Vivier wrote: > > > >> Hi, > >> > >> I think the problem can be because tcp_l2_buf_fill_headers() has been moved out of > >> tcp_prepare_flags() and so moved after: > >> > >> if (th->fin || th->syn) > >> conn->seq_to_tap++; > >> > >> and con->seq_to_tap is also a parameter of tcp_l2_buf_fill_headers(). So it is increased > >> before and not after. > >> > >> Could you try: > >> > >> diff --git a/tcp.c b/tcp.c > >> index 6800209d4122..647f42291fcf 100644 > >> --- a/tcp.c > >> +++ b/tcp.c > >> @@ -1607,6 +1607,7 @@ static int tcp_prepare_flags(struct ctx *c, struct tcp_tap_conn *conn, > >> if (!tcp_update_seqack_wnd(c, conn, flags, &tinfo) && !flags) > >> return 0; > >> > >> + *optlen = 0; > >> if (flags & SYN) { > >> int mss; > >> > >> @@ -1643,7 +1644,6 @@ static int tcp_prepare_flags(struct ctx *c, struct tcp_tap_conn *conn, > >> *data++ = conn->ws_to_tap; > >> } else if (!(flags & RST)) { > >> flags |= ACK; > >> - *optlen = 0; > >> } > >> > >> th->doff = (sizeof(*th) + *optlen) / 4; > >> @@ -1663,10 +1663,6 @@ static int tcp_prepare_flags(struct ctx *c, struct tcp_tap_conn *conn, > >> if (th->fin) > >> conn_flag(c, conn, ACK_FROM_TAP_DUE); > >> > >> - /* RFC 793, 3.1: "[...] and the first data octet is ISN+1." */ > >> - if (th->fin || th->syn) > >> - conn->seq_to_tap++; > >> - > >> return 1; > >> } > >> > >> @@ -1702,6 +1698,10 @@ static int tcp_send_flag(struct ctx *c, struct tcp_tap_conn *conn, > >> int flags) > >> conn->seq_to_tap); > >> iov[TCP_IOV_PAYLOAD].iov_len = l4len; > >> > >> + /* RFC 793, 3.1: "[...] and the first data octet is ISN+1." */ > >> + if (th->fin || th->syn) > >> + conn->seq_to_tap++; > >> + > >> if (flags & DUP_ACK) { > >> struct iovec *dup_iov; > >> int i; > > > > Ah, yes, good catch, I missed this one! It works. Note that it needs to > > be: > > > > if ((flags & FIN) || (flags & SYN)) > > ... > > > > because we don't have a TCP header there, yet. > > > > I'm wondering if I can do: > > + seq = conn->seq_to_tap; > ret = tcp_prepare_flags(c, conn, flags, &payload->th, > payload->opts, &optlen); > if (ret <= 0) > return ret; > > l4len = tcp_l2_buf_fill_headers(c, conn, iov, optlen, NULL, > - conn->seq_to_tap); > + seq); > > to keep the flags in tcp_prepare_flags()? Maybe, yes. I don't really have a strong preference. On the other hand tcp_send_flag() has to deal with the DUP_ACK case on its own anyway. But sure, this version would be a bit cleaner, and if vhost-user code will then want to call tcp_prepare_flags() without tcp_send_flag(), it avoids code duplication, I guess? -- Stefano