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 9E9AA5A02D1 for ; Tue, 30 Apr 2024 22:17:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714508232; 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=97/XnPIESiE4tl6YitXXL+lPUhw21x5+PNdgwZEz7o8=; b=WqskWY+lJxbNPVn/D/vrowUkQKv0jDbMw4A4aoRTsyeCVN5CI0Df1yiWxVzlGCwaRfXXYG b+2T3QkqTgQkPmGV+y8bAEpA56zd2PK/V/kFpyutPeRZ6olpXcLgBqifpYaBut85RVElGV z7HCpVnxKqwks1J6Y2qePyLBrwQoxqY= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-390-143pZpaAMYCrG5SdnU6WfQ-1; Tue, 30 Apr 2024 16:17:11 -0400 X-MC-Unique: 143pZpaAMYCrG5SdnU6WfQ-1 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-a59324b5fb3so62933966b.0 for ; Tue, 30 Apr 2024 13:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714508229; x=1715113029; 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=97/XnPIESiE4tl6YitXXL+lPUhw21x5+PNdgwZEz7o8=; b=OqwfpskmblAqNMUE5YRh47kSLjG6egdhANZjYSSEPnCLHDN1nntFZ5jyAtEFCqRXcK 4+ERez73JI/Ck2lbPgWGGCpV56XGA9vDHlL8qvgeavrHmRh3VDFZFPMU/LQ9+yj40PBW K4tFzjjy15Cn09fyDiCPDzpewfEFYIj4G1G+IQRstKzGrABNJLb2JNlQau5fhA2BMnxZ 7PR+j/d7h6ARenovykYYp3KSiYrLVkqhdFtCkujacINOvZivkfhtH7DQxfb7JY5rhzEv 4W43lS65zyEYGHczd6vnyVd6AdIqpzkUe9D9BNKA0RtCmvhNb6OzXZA2vCDU/S1k8/gF AHVA== X-Gm-Message-State: AOJu0Yyu9jUbMZxf26H9bsKLavp5/BQZbDmfJPltIZ8VEanT62EuRJC5 D09bcWJE0PJKSfkqJL14UFPFbbKtQFWTqUlsOU1NrCbTG2kDmVlSAwFaYmA5ZJ3U9E0/9XaM25f dSGei3EB6IW42VCkA1Qdj8gYUvVA4MQeCXr68MjOhrJvVl1UJKiizx5jrr7/C X-Received: by 2002:a17:906:af94:b0:a59:39da:5e07 with SMTP id mj20-20020a170906af9400b00a5939da5e07mr530436ejb.19.1714508228879; Tue, 30 Apr 2024 13:17:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHrPjMuUohfNsGcX32ArTm9HNL2LH6gA/AzP04/kJQQ/RWTaMWTz58NFLfRa9DTqSgL3hAf0w== X-Received: by 2002:a17:906:af94:b0:a59:39da:5e07 with SMTP id mj20-20020a170906af9400b00a5939da5e07mr530425ejb.19.1714508228309; Tue, 30 Apr 2024 13:17:08 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id cf8-20020a170906b2c800b00a58d14479adsm5432360ejb.59.2024.04.30.13.17.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2024 13:17:07 -0700 (PDT) Date: Tue, 30 Apr 2024 22:16:34 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 7/7] udp: Single buffer for IPv4, IPv6 headers and metadata Message-ID: <20240430221634.5f7dbf39@elisabeth> In-Reply-To: <20240430100541.381350-8-david@gibson.dropbear.id.au> References: <20240430100541.381350-1-david@gibson.dropbear.id.au> <20240430100541.381350-8-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.36; 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: UXKVQN6W4XOIGHD4AEXFY5JNGY36A3EX X-Message-ID-Hash: UXKVQN6W4XOIGHD4AEXFY5JNGY36A3EX 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, 30 Apr 2024 20:05:41 +1000 David Gibson wrote: > Currently we have separate arrays for IPv4 and IPv6 which contain the > headers for guest-bound packets, and also the originating socket address. > We can combine these into a single array of "metadata" structures with > space for both pre-cooked IPv4 and IPv6 headers, as well as shared space > for the tap specific header and socket address (using sockaddr_inany). This is neat, definitely, I just wonder: will we need to essentially revert this if we implement a flow-based mechanism where frames can be sent to different guests/containers? On the other hand, chances are it would help instead because we would have tables of metadata instead of those being buried into frames. > Because we're using IOVs to separately address the pieces of each frame, > these structures don't need to be packed to keep the headers contiguous > so we can more naturally arrange for the alignment we want. > > Signed-off-by: David Gibson > --- > udp.c | 131 ++++++++++++++++++++++++---------------------------------- > 1 file changed, 55 insertions(+), 76 deletions(-) > > diff --git a/udp.c b/udp.c > index 64e7dcef..a9cc6ed2 100644 > --- a/udp.c > +++ b/udp.c > @@ -184,44 +184,27 @@ udp_payload_buf[UDP_MAX_FRAMES]; > /* Ethernet header for IPv4 frames */ > static struct ethhdr udp4_eth_hdr; > > -/** > - * udp4_l2_buf_t - Pre-cooked IPv4 packet buffers for tap connections > - * @s_in: Source socket address, filled in by recvmmsg() > - * @taph: Tap backend specific header > - * @iph: Pre-filled IP header (except for tot_len and saddr) > - */ > -static struct udp4_l2_buf_t { > - struct sockaddr_in s_in; > - > - struct tap_hdr taph; > - struct iphdr iph; > -} __attribute__ ((packed, aligned(__alignof__(unsigned int)))) > -udp4_l2_buf[UDP_MAX_FRAMES]; > - > /* Ethernet header for IPv6 frames */ > static struct ethhdr udp6_eth_hdr; > > /** > - * udp6_l2_buf_t - Pre-cooked IPv6 packet buffers for tap connections > - * @s_in6: Source socket address, filled in by recvmmsg() > + * udp_meta - Pre-cooked headers and metadata for UDP packets Pre-existing, but... kernel-doc format wants *struct* x - Description. > + * @ip6h: Pre-filled IPv6 header (except for payload_len and addresses) > + * @ip4h: Pre-filled IPv4 header (except for tot_len and saddr) > * @taph: Tap backend specific header > - * @ip6h: Pre-filled IP header (except for payload_len and addresses) > + * @s_in: Source socket address, filled in by recvmmsg() > */ > -struct udp6_l2_buf_t { > - struct sockaddr_in6 s_in6; > -#ifdef __AVX2__ > - /* Align ip6h to 32-byte boundary. */ > - uint8_t pad[64 - (sizeof(struct sockaddr_in6) + sizeof(struct tap_hdr))]; > -#endif > - > - struct tap_hdr taph; > +static struct udp_meta { > struct ipv6hdr ip6h; > + struct iphdr ip4h; > + struct tap_hdr taph; > + > + union sockaddr_inany s_in; > +} > #ifdef __AVX2__ > -} __attribute__ ((packed, aligned(32))) > -#else > -} __attribute__ ((packed, aligned(__alignof__(unsigned int)))) > +__attribute__ ((aligned(32))) > #endif > -udp6_l2_buf[UDP_MAX_FRAMES]; > +udp_meta_buf[UDP_MAX_FRAMES]; > > /** > * enum udp_iov_idx - Indices for the buffers making up a single UDP frame > @@ -315,49 +298,46 @@ void udp_update_l2_buf(const unsigned char *eth_d, const unsigned char *eth_s) > static void udp_iov_init_one(const struct ctx *c, size_t i) > { > struct udp_payload *payload = &udp_payload_buf[i]; > + struct udp_meta *meta = &udp_meta_buf[i]; > struct iovec *siov = &udp_l2_iov_sock[i]; > > + *meta = (struct udp_meta) { > + .ip4h = L2_BUF_IP4_INIT(IPPROTO_UDP), > + .ip6h = L2_BUF_IP6_INIT(IPPROTO_UDP), > + }; > + > + One extra newline should be enough. -- Stefano