From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from imap.gmail.com [173.194.76.109] by localhost with POP3 (fetchmail-6.3.26) for (single-drop); Sun, 19 May 2024 09:04:40 +0200 (CEST) Received: by 2002:a05:6a10:271d:b0:547:81a2:46ee with SMTP id ib29csp6373747pxb; Sun, 19 May 2024 00:04:12 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCX6VsoKMeYBTZzLyY2RiioHZT1yl/B09mAeAtXBkg747V+DQ0CmPg+GzYOd7g+Rc9KQlMYi/XoZW/RIxh8R3jSZ2ScL6W1I8Gk= X-Google-Smtp-Source: AGHT+IGgaE5ZaaRsEg5419v40qFCKvqGPkMnJFKiDTePDGGFGZn2cE0HuTXwLk9PXPyjkxkNceo5 X-Received: by 2002:a05:6830:ed9:b0:6f0:8c66:ca1e with SMTP id 46e09a7af769-6f0e91141dcmr26476483a34.2.1716102252083; Sun, 19 May 2024 00:04:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1716102252; cv=none; d=google.com; s=arc-20160816; b=OQrSIB9FYd6nymG3yA30awOirsm019ejDGD+7o64D97r7olgR6XzHvYbadf1fyPeJ9 wlY42wfpbRG0RkJ/BFArK7J7CFPCe1pYB9gbYiF8jw+9qNaV9f+vV/u51Z7on0gCsDKl RiUsJrly82YLQ12cYslmJ5ft0abwcH34EFHM8lcgt34jODuw+7OH2KK15aKC4qAbrt0z EiPg5dB661+ZZInVpoQtwkOWBilv5vBbWPiPpM3RE6oWCiNzoTsJZJOL+DOAKKEWtjX8 VT0upfHnDW3VYH8K+QhwKil6nSCUdhLuIVs8V9Oi6XWKC16kH16wswicaGVUy6Wv8pTQ 63QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:dkim-signature:delivered-to; bh=YpxcKSn5ChoWUFVblvUNDSPhG+X4iuKmuGpgN3DxzC8=; fh=htis3z6nDPD3FFPmKX7SGQyhLv1B9tDlnJYWrC8d10o=; b=zBMHKaCTWHI1MFg7nVoQvOcI+mWz/0clS1UZU8gLaY3Hi5aLRblAOAbiUP4GgC237/ xcNCq9h4TjDvSflj3p6QyQcIOm+9j3R9xOMX2wH2f6yrzuyI6pzyUk7WW71Eg5ndwMXF 15cgblj1Fiqms2aNLgHTqjNw/QONocpBiX7lKxsn74BE67C1Rn4f/0j61mAAFZpkRxcm X6qprw4mXUrQ0+BSdQ2MFvOOoRX/PQHtSfm+c52IicCdlnk1bz43UgrXmQdRCY3hRT7M r+rLuduPY439j9Gmgb3pvc7GMGfz+2hBgkSOwnKZb+XvpHcuFq50NU2z+kD25fEYMjQX DXLw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@gibson.dropbear.id.au header.s=202312 header.b=eKDPW7wn; spf=pass (google.com: domain of dgibson@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) smtp.mailfrom=dgibson@gandalf.ozlabs.org Return-Path: Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com. [205.139.110.120]) by mx.google.com with ESMTPS id af79cd13be357-792bf30a948si38541885a.301.2024.05.19.00.04.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 May 2024 00:04:11 -0700 (PDT) Received-SPF: pass (google.com: domain of dgibson@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) client-ip=150.107.74.76; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@gibson.dropbear.id.au header.s=202312 header.b=eKDPW7wn; spf=pass (google.com: domain of dgibson@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) smtp.mailfrom=dgibson@gandalf.ozlabs.org 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-120-Ln2WQA7XNkybhMCLVdD8rA-1; Sun, 19 May 2024 03:04:09 -0400 X-MC-Unique: Ln2WQA7XNkybhMCLVdD8rA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (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 44594101A525 for ; Sun, 19 May 2024 07:04:09 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 410911054820; Sun, 19 May 2024 07:04:09 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08169105480A for ; Sun, 19 May 2024 07:04:08 +0000 (UTC) Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [170.10.128.131]) (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 CA5F63C025C6 for ; Sun, 19 May 2024 07:04:08 +0000 (UTC) Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-59-JGwMl2YsPzy4ELapmx7pdQ-1; Sun, 19 May 2024 03:04:05 -0400 X-MC-Unique: JGwMl2YsPzy4ELapmx7pdQ-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1716102240; bh=YpxcKSn5ChoWUFVblvUNDSPhG+X4iuKmuGpgN3DxzC8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eKDPW7wnsBuBnaq6x0j0T2o7szfQzeFMq+F9MXVkkpw6O+qT/SfDutzSl4OeKFu3m +P00odPaUNswThKbaH1NPnP1VY8x0YCXbmbjCov0bin8LeX/LcvBWKm3DExSOBGBq+ Ea5nyZzxJzXlcqGwPt10NnNKI7UST3hKtzNzhZ2XtgLPMKluKXtkHY9CmrDqe4bK/g dUC6ZMNcyhzJJyTKSld0q0Uqhw25GfodKcGih4S6/8vqq0X2MfOlTwqF43dC6pFNIV UDV6FPXa5Y4S8GiFDeVOUZrOKzh2N19h+/Gf7QrgWPJmR5u9faXtIFWfCFyBklG8KC XZrWTMpSnCNPQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4VhsB83Mc7z4wjF; Sun, 19 May 2024 17:04:00 +1000 (AEST) Date: Sat, 18 May 2024 16:47:46 +1000 From: David Gibson To: Stefano Brivio Cc: passt-dev@passt.top Subject: Re: [PATCH v5 01/19] flow: Clarify and enforce flow state transitions Message-ID: References: <20240514010337.1104606-1-david@gibson.dropbear.id.au> <20240514010337.1104606-2-david@gibson.dropbear.id.au> <20240516113058.1e8f0b66@elisabeth> <20240517130044.6bb8ce53@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YWPrwFcBbpToCEcZ" Content-Disposition: inline In-Reply-To: <20240517130044.6bb8ce53@elisabeth> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 List-Id: --YWPrwFcBbpToCEcZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 17, 2024 at 01:00:44PM +0200, Stefano Brivio wrote: > On Fri, 17 May 2024 13:57:58 +1000 > David Gibson wrote: >=20 > > On Thu, May 16, 2024 at 11:30:58AM +0200, Stefano Brivio wrote: > > > On Tue, 14 May 2024 11:03:19 +1000 > > > David Gibson wrote: > > > =20 > > > [...] > > > > > > > /** > > > > * struct flow_common - Common fields for packet flows > > > > + * @state: State of the flow table entry > > > > * @type: Type of packet flow > > > > */ > > > > struct flow_common { > > > > + uint8_t state; =20 > > >=20 > > > In this case, I would typically do > > > (https://seitan.rocks/seitan/tree/common/gluten.h?id=3D5a9302bab9c9bb= 3d1577f04678d074fb7af4115f#n53): > > >=20 > > > #ifdef __GNUC__ > > > enum flow_state state:8; > > > #else > > > uint8_t state; > > > #endif =20 > >=20 > > I don't object to that, but I have two questions > >=20 > > - What's the advantage to using the explicit enum? Is that for the > > benefit of static checkers and/or compiler diagnostics? >=20 > Yes: if we assign a value that's not in the enum, I expect static > checkers to complain. But also for humans: even with that ifdef, a > reader would know right away what values that might have. >=20 > > AFAIK C > > itself doesn't really treat enums any differently to integer > > types. >=20 > Right. >=20 > > - What's the need for GNUC? Are enum bitfields a gnu extension? >=20 > They're rather permitted by gcc's interpretation of the standard: >=20 > https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Structures-unions-enumera= tions-and-bit-fields-implementation.html >=20 > Allowable bit-field types other than _Bool, signed int, and unsigned > int (C99 and C11 6.7.2.1). >=20 > Other integer types, such as long int, and enumerated types are permitt= ed > even in strictly conforming mode. >=20 > but C11 says (6.7.2.1): >=20 > A bit-field shall have a type that is a qualified or unqualified > version of _Bool, signed int, unsigned int, or some other > implementation-defined type. It is implementation-defined whether > atomic types are permitted. >=20 > Is an enum a "version" of those? Maybe not. That was at least the > interpretation adopted by older gcc versions, up to 4.7.4: >=20 > https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Structures-unions-enumerat= ions-and-bit-fields-implementation.html >=20 > Allowable bit-field types other than _Bool, signed int, and unsigned > int (C99 6.7.2.1). >=20 > No other types are permitted in strictly conforming mode. >=20 > Did that change from C99? Not really: >=20 > A bit-field shall have a type that is a qualified or unqualified > version of _Bool, signed int, unsigned int, or some other > implementation-defined type. >=20 > > Even versus C11, which we already require? >=20 > Yes, I would say it doesn't change things. Only C23 would improve that: > https://open-std.org/JTC1/SC22/WG14/www/docs/n3030.htm#design-constant.= type >=20 > by allowing us to define the underlying type. Ah, ok. Makes sense, I've made that change. > > > ...and in any case we need to make sure to assign single values in the > > > enum above: there are no guarantees that FLOW_STATE_ACTIVE is 3 > > > otherwise (except for that static_assert(), but that's not its purpos= e). =20 > >=20 > > I'm not clear how this comment relates to the one before. >=20 > It's unrelated, but: >=20 > > AFAIK > > nothing in here (or the rest of the series) relies on the specific > > numeric values of the flow state values (although we do rely on them > > being ordered as written in some places). >=20 > while we rely on the fact that no value is bigger than 255, I realised > that the standards already guarantee that values start from 0 and every > subsequent constant is defined as one more than the previous one, all > the way from C90 to C11, so this would actually be fine. Right, I was expecting that behaviour - the way we define FLOW_NUM_STATES and similar things in a bunch of places relies on this. > Sorry, I don't know exactly why I thought that wouldn't be the case, I > was pretty sure of the opposite until I checked. Ok. I've scattered in some extra static_assert()s in the vicinity, too. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --YWPrwFcBbpToCEcZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmZITv4ACgkQzQJF27ox 2GckVg//ZTePOWNP/IFvjr/ruVSSXxo+0F0jPDYHxvwMLN8XtRGe5HUlWsTa1KRC MrY9G0ooHkNjhM/pJGSxaYwBHBUpmXKu5roXWVpzazO5JkpHX3scPbh8ZuWeHLBQ 7G3+Wv9mQt9P/RW6/pssClcaiWdLID1d2OdjhZIr1cgxVZf4eQ+wEE8dAtLi8jcS HX3zMT36aVLZ0UMz0Nli+EW23Sh8pn3WAFOKhfXTlaARPcO2gmZU0jOBcefmxYfo WDxvuKYHCN3RlMAnwJIUQAmD+88pqWduxyHh8Ai1ms6sppJ7IuAvhiGR+oFCktxk QoQwVFvTb2pWcJWfG/FidEe7/mAeBeC1e5u2+5HxN2D1pLJ4gFKfZYISoibLQJHI c/0LrO8gXwa2pgmWNlRlC/bgVWLawx13o+Bmg+/2mOAGTko76LunbqaBd5/9KMAA rrHELxbyo/z7Z+mZMuvzOOmyUKcNQHl9vbYxkh2GAl77Noe3hVGU+QjzX6Higr58 jT7DB+ZIDd4Z8jY2UMHp1ZQanIul52UQ/N7No1zvhBdnXODe01Mf1YNyobtDv3x5 fEeNSiL7H3pQwvvEKIUBxW8/HCC60KZXRshHtLoEqiaaTK5uXRcdEvTkyeIZbvST 5PIJ7QD08+ny36HxSAtSq/7k2DQmsBAtoJBAfwOUnEj+9DHifa8= =DtjL -----END PGP SIGNATURE----- --YWPrwFcBbpToCEcZ--