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 208D15A0272 for ; Tue, 2 Jan 2024 19:13:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704219219; 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=pSsKMUf0P8PrKmhEmz8Ms6oAjGolIenOSo0ezvf8MpU=; b=O6t0Nh0TdKEGMMplc/uk6qUaT2zOPCJ8u/Mj5mI9L6oeijXtWapR6Es8KcEkqHSi5CDywo b03M9TdBSozzMvPy/GsMFcWeREfB8tfI6JrcyVzVb82Lr8FSKuyyqJ/0ppIbkY2dRaKs/F UDpX3qLejx2V/JDIKn3ZMOLzvI/bRKQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-330-IHRf8aHRP7a37G47FzN7GA-1; Tue, 02 Jan 2024 13:13:38 -0500 X-MC-Unique: IHRf8aHRP7a37G47FzN7GA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EC00E101A551; Tue, 2 Jan 2024 18:13:37 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2DE21492BF0; Tue, 2 Jan 2024 18:13:36 +0000 (UTC) Date: Tue, 2 Jan 2024 19:13:35 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 10/13] flow: Move flow_count from context structure to a global Message-ID: <20240102191335.413b2b04@elisabeth> In-Reply-To: References: <20231221061549.976358-1-david@gibson.dropbear.id.au> <20231221061549.976358-11-david@gibson.dropbear.id.au> <20231228192459.312cc508@elisabeth> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: OSLBTHSJRWNZHKJI5MBSBFXTJVJOSUJ3 X-Message-ID-Hash: OSLBTHSJRWNZHKJI5MBSBFXTJVJOSUJ3 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 Sun, 31 Dec 2023 16:58:39 +1100 David Gibson wrote: > On Thu, Dec 28, 2023 at 07:25:18PM +0100, Stefano Brivio wrote: > > On Thu, 21 Dec 2023 17:15:46 +1100 > > David Gibson wrote: > > =20 > > > In general, the passt code is a bit haphazard about what's a true glo= bal > > > variable and what's in the quasi-global 'context structure'. The > > > flow_count field is one such example: it's in the context structure, > > > although it's really part of the same data structure as flowtab[], wh= ich > > > is a genuine global. =20 > >=20 > > Well, the reason is that flow_tab[FLOW_MAX] might be problematically > > too big to live on the stack, unlike flow_count. > >=20 > > But anyway, as far as thoughts of multithreading are concerned, both > > should probably be global. And sure, it's more consistent this way. > > =20 > > > Move flow_count to be a regular global to match. For now it needs to= be > > > public, rather than static, but we expect to be able to change that i= n > > > future. =20 > >=20 > > If it's not static, it should be initialised, and that's not done here.= =20 >=20 > Uh... what? "static" here is meaning module-global rather than > global-global, which has no bearing on initialisation. AFAIK globals > are zero-initialised whether they're static or not. ...and to my utter surprise, I just discovered that if you talk C11, you're right. From the N1570 draft (ISO/IEC 9899:201x), Section 6.7.9 "Initialization", clause 10: If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static or thread storage duration is not initialized explicitly, then: [...] =E2=80=94 if it has arithmetic type, it is initialized to (positive or unsigned) zero; And 'flow_count' has thread storage duration. In C99, however (draft N1256), Section 6.7.8 "Initialization", clause 10: If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: [...] note the missing "or thread storage duration". C89, the one I was actually basing my observation on, says, at 3.5.7 "Initialization": If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant. If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. so... um. We won't go back to C99. But to me, and maybe others, not having a "=3D 0;" for a "global" means pretty much that we don't rely on any particular initial value. If you're strongly against it, fine, C11 says it's zero... but it makes me a bit nervous nevertheless. --=20 Stefano