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 334685A0274 for ; Wed, 13 Mar 2024 16:20:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710343222; 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=Kc0r9PzsmvF0PC9Dv15pFd5GxfTTtSysucJ4ogBg8GQ=; b=hpASlBIDS53dVwEJgAbDk/UdcM7fFQuIvILOmP1XEog9RKJSd8eymwQWyJbvZ5Bhj0l5Yp U8MV/+FAOzDiAsIz43HoKi0pZFHyytgUro1Hy2XNZzipIzfFvz69EaMIWFko32b4J5i6Hg VdvVCLC33VyLJCE0rvgCZbPTlgmgKew= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-80-wt2EveklN0m_KxYANmNYCg-1; Wed, 13 Mar 2024 11:20:17 -0400 X-MC-Unique: wt2EveklN0m_KxYANmNYCg-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-412db0e24aeso5804265e9.1 for ; Wed, 13 Mar 2024 08:20:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710343215; x=1710948015; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Kc0r9PzsmvF0PC9Dv15pFd5GxfTTtSysucJ4ogBg8GQ=; b=EL7bfcM5cS8WfKGhmGTFK4K9YFhvN3SOyJVVGRz8dyeTf5lPJVEmi/xSh0J4v57JRX H/WRaA07CR/+OedcaWp44oZheg34ksJW3MEC6lzhyZLHSVEqTExdm6SFhapsiEYNiJ7R Ys9ZduaYS6cjLI7jOs0qavQbd5T/UKm7MqlCTcFrRRifSReAWkJUNGlRmBftK+/MVoAo 4fcR/H4tG0LK63/qL5Y2bZFvFLkry9HkYktXHbAtdlMEKMnikw3J3onEQP0sbaKXqZi7 GWTtH4HhnPUenyD0TSF9+RIo8E9uFo9K9Sj0blr7/1w4fx/1UmM384ZCieBA7I4t/oGT /NmQ== X-Gm-Message-State: AOJu0YwDxyC1LvNnDJjTva5k/yaguXN5rXJjrzSJf8uI7P7bs4k7nFnU 6FOb4UkZueOwR7qpVyHWb8OIuVso4dE+5XfEPBvOFe0hKkt57DyVgCuygSVQqzaxUqPPnfUbozx auJ+IK1wE1ovIPxM2xQPNaLe9/r5C9N8uG5EXXc82JouYSzThMMW4/4KXPw== X-Received: by 2002:a05:600c:4ecc:b0:413:129d:66b6 with SMTP id g12-20020a05600c4ecc00b00413129d66b6mr229533wmq.15.1710343215274; Wed, 13 Mar 2024 08:20:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFz5qRwWwRo73eGVjRbUzk4ZNHnPyyKiA3l7iTg/a4YS1PqWw8pHNpj/QZiP4HLNWtejJGBwQ== X-Received: by 2002:a05:600c:4ecc:b0:413:129d:66b6 with SMTP id g12-20020a05600c4ecc00b00413129d66b6mr229512wmq.15.1710343214862; Wed, 13 Mar 2024 08:20:14 -0700 (PDT) Received: from [192.168.100.30] ([82.142.8.70]) by smtp.gmail.com with ESMTPSA id d3-20020a05600c34c300b00413eac2e806sm1965049wmq.29.2024.03.13.08.20.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Mar 2024 08:20:13 -0700 (PDT) Message-ID: <96b64a53-ad12-4fb3-9ff6-225e82df7c09@redhat.com> Date: Wed, 13 Mar 2024 16:20:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] tcp: Replace TCP buffer structure by an iovec array To: Stefano Brivio References: <20240311133356.1405001-1-lvivier@redhat.com> <20240313123725.7a37f311@elisabeth> From: Laurent Vivier In-Reply-To: <20240313123725.7a37f311@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: SYIJXZPGRKYI5Y5MHUXXML3OLNIO735R X-Message-ID-Hash: SYIJXZPGRKYI5Y5MHUXXML3OLNIO735R X-MailFrom: lvivier@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 3/13/24 12:37, Stefano Brivio wrote: > On Mon, 11 Mar 2024 14:33:56 +0100 > Laurent Vivier wrote: > ... >> @@ -445,133 +413,78 @@ struct tcp_buf_seq_update { >> }; >> >> /* Static buffers */ >> - >> /** >> - * tcp4_l2_buf_t - Pre-cooked IPv4 packet buffers for tap connections >> - * @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) >> - * @uh: Headroom for TCP header >> - * @data: Storage for TCP payload >> + * tcp_l2_flags_t - TCP header and data to send option flags > > 'struct tcp_l2_flags_t - ...', by the way (pre-existing, I see). > >> + * @th: TCP header >> + * @opts TCP option flags >> */ >> -static struct tcp4_l2_buf_t { >> -#ifdef __AVX2__ >> - uint8_t pad[26]; /* 0, align th to 32 bytes */ >> -#else >> - uint8_t pad[2]; /* align iph to 4 bytes 0 */ >> -#endif >> - struct tap_hdr taph; /* 26 2 */ >> - struct iphdr iph; /* 44 20 */ >> - struct tcphdr th; /* 64 40 */ >> - uint8_t data[MSS4]; /* 84 60 */ >> - /* 65536 65532 */ >> +struct tcp_l2_flags_t { >> + struct tcphdr th; >> + char opts[OPT_MSS_LEN + OPT_WS_LEN + 1]; >> +}; > > This should still be aligned (when declared below) with: > > #ifdef __AVX2__ > } __attribute__ ((packed, aligned(32))) > #else > } __attribute__ ((packed, aligned(__alignof__(unsigned int)))) > #endif > > because yes, now you get the unsigned int alignment for free, but the > 32-byte boundary for AVX2 (checksums) not really, so that needs to be > there, and then for clarity I would keep the explicit attribute for the > non-AVX2 case. > > By the way, I guess you could still combine the definition and > declaration as it was done earlier. We can't combine the definition and declaration because the same definition is used with IPv4 and IPv6 TCP arrays declaration. I'm not sure: the __attribute__ must be used on the structure definition or on the array of structures declaration? Thanks, Laurent