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.133.124]) by passt.top (Postfix) with ESMTP id 1F5F75A026F for ; Tue, 22 Aug 2023 10:46:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692694007; 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=seik+00NhIPTJ900EfmmQIt9q0BLvUeDWShkgP4MZ+Y=; b=AOC1HNj9r46ogGomHaRtyMuLAe0vzBDOuBAhZYej9tbHKyEbUqJgepSAYwax2C0//im/uo 22sQDlPgZi89c8tbLN6gF1OiwCFsH56uzdpRlgPaT6tvv+hBRtvByfba/VDu2wDt/cxK0O 4MFsr6sflh2Yd9y1PdQEC1gbnPgvXF4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-588-ewA_mIXvMAqoA4d8aI5X-w-1; Tue, 22 Aug 2023 04:46:43 -0400 X-MC-Unique: ewA_mIXvMAqoA4d8aI5X-w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5B7C58D40AF; Tue, 22 Aug 2023 08:46:43 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 810532166B28; Tue, 22 Aug 2023 08:46:42 +0000 (UTC) Date: Tue, 22 Aug 2023 10:46:38 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v4 5/9] tcp, udp: Don't include destination address in partially precomputed csums Message-ID: <20230822104638.2ddd1888@elisabeth> In-Reply-To: <20230822053000.1118063-6-david@gibson.dropbear.id.au> References: <20230822053000.1118063-1-david@gibson.dropbear.id.au> <20230822053000.1118063-6-david@gibson.dropbear.id.au> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: E65QXT6XEFRIZIK5YEITQQP6BM7XLZRI X-Message-ID-Hash: E65QXT6XEFRIZIK5YEITQQP6BM7XLZRI 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 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 Tue, 22 Aug 2023 15:29:56 +1000 David Gibson wrote: > We partially prepopulate IP and TCP header structures including, amongst > other things the destination address, which for IPv4 is always the known > address of the guest/namespace. We partially precompute both the IPv4 > header checksum and the TCP checksum based on this. > > In future we're going to want more flexibility with controlling the > destination for IPv4 (as we already do for IPv6), so this precomputed value > gets in the way. Therefore remove the IPv4 destination from the > precomputed checksum and fold it into the checksum update when we actually > send a packet. > > Doing this means we no longer need to recompute those partial sums when > the destination address changes ({tcp,udp}_update_l2_buf()) and instead > the computation can be moved to compile time. This means while we perform > slightly more computations on each packet, we slightly reduce the amount of > memory we need to access. > > Signed-off-by: David Gibson > --- > tcp.c | 61 ++++++++++++++++++++-------------------------------------- > udp.c | 14 +++----------- > util.h | 4 +++- > 3 files changed, 27 insertions(+), 52 deletions(-) > > diff --git a/tcp.c b/tcp.c > index 56634c9..c52ea2b 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -323,10 +323,8 @@ > #define MSS_DEFAULT 536 > > struct tcp4_l2_head { /* For MSS4 macro: keep in sync with tcp4_l2_buf_t */ > - uint32_t psum; > - uint32_t tsum; > #ifdef __AVX2__ > - uint8_t pad[18]; > + uint8_t pad[26]; > #else > uint8_t pad[2]; > #endif > @@ -443,8 +441,6 @@ static union inany_addr low_rtt_dst[LOW_RTT_TABLE_SIZE]; > > /** > * tcp4_l2_buf_t - Pre-cooked IPv4 packet buffers for tap connections > - * @psum: Partial IP header checksum (excluding tot_len and saddr) > - * @tsum: Partial TCP header checksum (excluding length and saddr) > * @pad: Align TCP header to 32 bytes, for AVX2 checksum calculation only > * @taph: Tap-level headers (partially pre-filled) > * @iph: Pre-filled IP header (except for tot_len and saddr) > @@ -452,17 +448,15 @@ static union inany_addr low_rtt_dst[LOW_RTT_TABLE_SIZE]; > * @data: Storage for TCP payload > */ > static struct tcp4_l2_buf_t { > - uint32_t psum; /* 0 */ > - uint32_t tsum; /* 4 */ > #ifdef __AVX2__ > - uint8_t pad[18]; /* 8, align th to 32 bytes */ > + uint8_t pad[26]; /* 0, align th to 32 bytes */ > #else > - uint8_t pad[2]; /* align iph to 4 bytes 8 */ > + uint8_t pad[2]; /* align iph to 4 bytes 0 */ > #endif > - struct tap_hdr taph; /* 26 10 */ > - struct iphdr iph; /* 44 28 */ > - struct tcphdr th; /* 64 48 */ > - uint8_t data[MSS4]; /* 84 68 */ > + struct tap_hdr taph; /* 26 2 */ > + struct iphdr iph; /* 44 20 */ > + struct tcphdr th; /* 64 40 */ > + uint8_t data[MSS4]; /* 84 60 */ > /* 65536 65532 */ Pre-existing, but I spotted this only now: the non-AVX2 version ends at 65532 because MSS4 is 65535 - 68 rounded down to a multiple of 4. But USHRT_MAX is used in MSS4() just to make sure we don't exceed it as frame size (right?) -- after https://bugs.passt.top/show_bug.cgi?id=55 I'm kind of wondering if we shouldn't start from 65536 instead and gain those four bytes back. Unrelated, anyway. The series looks good to me, thanks, applying in a bit. -- Stefano