From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id ACEEC5A027F for ; Fri, 1 Dec 2023 01:11:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1701389467; bh=Vbf91S2enB07ydDSmrVsAWljj78nDyRArCW3wKDSnmk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=F4FgkA//zi5supaRBk6+QTAErdfz4Z47fDiyMuaq0woeC7+BJ+AAxuzu989FAsmiE 7du7LnhouAhOisiamUyBJx5uXlPskqtQ+B759+bkHtXhUWCTMAVV2TuMSy8uUHoeiS TS2zeAt8f+8LdxpzL9crOARiRCsnTFi+EPXFmN24= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4ShD4C1RkYz4x5q; Fri, 1 Dec 2023 11:11:07 +1100 (AEDT) Date: Fri, 1 Dec 2023 11:10:56 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v2 07/11] flow: Introduce 'sidx' type to represent one side of one flow Message-ID: References: <20231126233348.1599864-1-david@gibson.dropbear.id.au> <20231126233348.1599864-8-david@gibson.dropbear.id.au> <20231129153232.6abfe53c@elisabeth> <20231130102116.273f0e18@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A8Gb4KYFYEs6E3Eo" Content-Disposition: inline In-Reply-To: <20231130102116.273f0e18@elisabeth> Message-ID-Hash: 254YJ5SBFFDR4XPKBLFZSQ26BIRARP7M X-Message-ID-Hash: 254YJ5SBFFDR4XPKBLFZSQ26BIRARP7M X-MailFrom: dgibson@gandalf.ozlabs.org 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: --A8Gb4KYFYEs6E3Eo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 30, 2023 at 10:21:16AM +0100, Stefano Brivio wrote: > On Thu, 30 Nov 2023 11:37:40 +1100 > David Gibson wrote: >=20 > > On Wed, Nov 29, 2023 at 03:32:32PM +0100, Stefano Brivio wrote: > > > On Mon, 27 Nov 2023 10:33:44 +1100 > > > David Gibson wrote: > > > =20 > > > > In a number of places, we use indices into the flow table to identi= fy a > > > > specific flow. We also have cases where we need to identify a part= icular > > > > side of a particular flow, and we expect those to become more commo= n as > > > > we generalise the flow table to cover more things. > > > >=20 > > > > To assist with that, introduces flow_sidx_t, an index type which id= entifies > > > > a specific side of a specific flow in the table. > > > >=20 > > > > Signed-off-by: David Gibson > > > > --- > > > > flow.h | 13 +++++++++++++ > > > > flow_table.h | 36 ++++++++++++++++++++++++++++++++++++ > > > > 2 files changed, 49 insertions(+) > > > >=20 > > > > diff --git a/flow.h b/flow.h > > > > index b6da516..3c90bbd 100644 > > > > --- a/flow.h > > > > +++ b/flow.h > > > > @@ -39,6 +39,19 @@ struct flow_common { > > > > #define FLOW_TABLE_PRESSURE 30 /* % of FLOW_MAX */ > > > > #define FLOW_FILE_PRESSURE 30 /* % of c->nofile */ > > > > =20 > > > > +/** > > > > + * struct flow_sidx - ID for one side of a specific flow > > > > + * @side: Side referenced (0 or 1) > > > > + * @flow: Index of flow referenced > > > > + */ > > > > +typedef struct flow_sidx { =20 > > >=20 > > > Implying my usual argument :) ...is there any advantage over using th= is > > > simply as a struct? =20 > >=20 > > So, usually I too would prefer to use a struct as a struct, without a > > typedef. The reason I'm doing differently here, is that I want to > > emphasise that for many purposes this can be treated like an index, in > > particular that it's small and trivially copyable. In particular it > > should be passed by value, passing by reference would be silly. >=20 > Hmm, that was exactly my "not hiding" point though. The day somebody > adds here: >=20 > char mood[RLIMIT_STACK_VAL + 1]; /* list of side emojis */ >=20 > the typedef makes it still apparently okay to pass by value. If it's a > struct, one surely has to check first. Right.. and that's kind of the point. If someone adds that, this struct is no longer doing the job intended for it, and a wider redesign is needed. That's why there's also the static_assert() verifying that flow_sidx_t fits in a u32. > > That's kind of the opposite of what one tends to be conveying by > > reminding users that they're working with a struct. >=20 > I see, but it's probably a matter of taste (passing structs by value > doesn't personally make me nervous). >=20 --=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 --A8Gb4KYFYEs6E3Eo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmVpJJAACgkQzQJF27ox 2GeEIQ/+PKGSmvPtcdB+xtaqiUeit7vPQRs//qk/pr0byTEf4ydjx6ooQMhDhX9u E6OivYSQQVmX6K4XQ/LkHILEXauUtVCegNyvvphd3EEE6JC+/5YqkAyD2H0PLE6A qLvh1SfyBxV9RVpqBMmrivhAv3sYD8hePMXYhma9wmKDM4tOPk3bGTJRdZYQlUSE sw/aSilLSOxIoYy9PfFupeKbznRSra4ncAf9fX1RjJj29zY+YGm+ZwG/l64BDAwe tXcSMgWHwqh+IR/1MCogvUdjheR9sAIMXenNgNYVqrEkGtfEy5iFX5LMDnzqUOwn YgVeFLwalMBU1ijFUDieNFwSQ0iKX0lva+n1+vWQZeQHl5gaqY9gFzO+j1FR3grU /v6MOCYRBZOtEdpvWURlJjI4YPRWDgsFH6T/37zKqqjIbKulUahMxKFiIU6VJ/ke k1BiAYAN6/ChtP+KKlKDmGpFQZFj6oFeVm3bhH695lOLGbJliVYDoWrY+87JQkk1 ZFvTu2sTd/jZUEzgpukJlS0rPlVkZjK9avBntLEXCSwtIIk4TffxBmMGaM15A4uH SKXnnj169BePD0qQTpDhAH8wxzWgz71UKvO5bgP4wBUW1V0HfmRYrd9TKfjTr1QU t6bQLBmPBYOsfLwREJ8DtaFIukO1yjCgUsXxhpbSpi5pNg3EJFo= =sF2C -----END PGP SIGNATURE----- --A8Gb4KYFYEs6E3Eo--