From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Jwp9Ikcp; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 7712A5A004C for ; Mon, 09 Sep 2024 10:31:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725870680; 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=bHzVOG3zthXlfLAmkRrxwF9IA4g5kdgN7TM/y5LVU+Y=; b=Jwp9IkcpJXmQnYQa2xB9hH7rsiMEpWZFqu6gadrRbOnXY/AiVHipsR/Jn/8n1Y+gBv0GVz wwgcjiCSfYnLYl6kile7Q3YBdJAoOOlJcja40ifkU8cb/dZtQyryVt0V/QrdRX/IV3RUuo CyxM1CPYeRNTryUsmfWiT26f+yb0bAI= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-220-8CkXlkxpMa6IwpHK8U1_pA-1; Mon, 09 Sep 2024 04:31:19 -0400 X-MC-Unique: 8CkXlkxpMa6IwpHK8U1_pA-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-42cb08ed3a6so6551685e9.0 for ; Mon, 09 Sep 2024 01:31:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725870677; x=1726475477; 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=bHzVOG3zthXlfLAmkRrxwF9IA4g5kdgN7TM/y5LVU+Y=; b=s+bYF9W1raXefUuwazus1Wj65VgzbalqLOr/221GKYymqAHI6lu/Gbt2w0KR6v9tym Z7kUV77HAlQyTSQJRhKjmmCwofrn7cIC3XsgjlqK0PhZQj647rqQnYgAJwGhINk7A1/j ZhHSz3PYzRnYTADqy2bU0q6JAomALwc2rIFefNaxFxLfo5kj7A4vyViH7xYhsZPNp6Zb VYFx177Cida3CE4tyY3AOOeKVdOAHG7XD8hR3UCdS2WWR+XuyoJty9CBf79IinA4G1C+ 40FpkrlRMFEkDIj4GaLiy9w/MAk30XeNOYCwhWcUEwEug7C6XMMau6GAa89G7sBb7iGP EUCw== X-Gm-Message-State: AOJu0Yy76TIFd08FRCCeUOq9+foF4NKGJ1tmH/OOHB/ONrO03mA0xYbU /2Wr4DtARdmZrfW0Q3BGuZGaa9sd93HDSKWV3brI1Op6RW3P4TtJ0PrxiofM8ypSGQ0AurCU+Mz 5grAwpndw9fHbanqP/2weeSZISHhxlFCUlEO12uO9PjaL1zBHlVxiiomMkaRKMJmsforPzM1vHY 8m2UNG2CU8VRUbvJj2IQm33kwIt6TnD76l X-Received: by 2002:a05:600c:5246:b0:42c:b8e5:34d5 with SMTP id 5b1f17b1804b1-42cb8e537d0mr9203415e9.15.1725870677463; Mon, 09 Sep 2024 01:31:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHfffkpXaG0/gfq2nuXJ96ww1KsvKLiI0Sj9wJTtDJpW1i69RgzoA12zlnWHjMbQbyGKChWeQ== X-Received: by 2002:a05:600c:5246:b0:42c:b8e5:34d5 with SMTP id 5b1f17b1804b1-42cb8e537d0mr9203175e9.15.1725870676959; Mon, 09 Sep 2024 01:31:16 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42caeb32b0csm69305775e9.18.2024.09.09.01.31.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2024 01:31:15 -0700 (PDT) Date: Mon, 9 Sep 2024 10:31:14 +0200 From: Stefano Brivio To: Jon Maloy Subject: Re: [PATCH 0/4] tcp: unify IPv4 and IPv6 l2 tap queues Message-ID: <20240909103114.12a73178@elisabeth> In-Reply-To: <20240906213427.1915806-1-jmaloy@redhat.com> References: <20240906213427.1915806-1-jmaloy@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: BUTHYQD5OU5GJNXZ2XYSVVQHHKN7ARTU X-Message-ID-Hash: BUTHYQD5OU5GJNXZ2XYSVVQHHKN7ARTU 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, lvivier@redhat.com, dgibson@redhat.com 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 Fri, 6 Sep 2024 17:34:23 -0400 Jon Maloy wrote: > This should save us some memory and code. > > Jon Maloy (4): > tcp: create unified struct for IPv4 and IPv6 header > tcp: update ip address in l2 tap queues on the fly > tcp: unify l2 TCPv4 and TCPv6 queues and structures > tcp: change prefix tcp4_ to tcp_ where applicable > > tcp.c | 22 ++--- > tcp_buf.c | 259 +++++++++++++++++------------------------------------- > tcp_buf.h | 3 + > 3 files changed, 98 insertions(+), 186 deletions(-) The saving in lines of code is nice (68 lines excluding comments), I'm not quite sure about memory savings and overhead. Memory-wise, if one IP version is disabled, we won't initialise any related buffer, so in that case we won't save any memory with these changes. If both IPv4 and IPv6 are enabled, we'll halve the memory usage for inbound payload buffers (about 8 MiB instead of 16 MiB): $ nm -td -P passt.avx2 | grep "tcp6_payload " tcp6_payload b 48607968 8388608 but that also halves the total amount of available buffers. If we have occasional usage of one IP family, these changes decrease waste, but if both IPv4 and IPv6 are used consistently, this simply means we're cutting the amount of buffers in half. However, we could double TCP_FRAMES_MEM and have, as a result, a more optimised management of buffers. But I'm not sure it makes sense considered the potential overhead. That is, there's a reason why I originally added two separate sets of buffers for IPv4 and IPv6: to enable pre-computations of headers, so that we avoid populating the full headers at every received packet. This series reverses that. There's the possibility that improvements in data locality and lower data cache usage outweigh that (as David mentioned in his comment to 1/4), but that should be demonstrated first. By the way, I tested this series, the clang-tidy test fails (see David's comment to 2/4) and the "TCP throughput over IPv6: guest to host" test consistently hangs as we switch to the 65520 bytes MTU. It looks like the iperf3 client fails to connect altogether, but I didn't really investigate. -- Stefano