From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 919D242572;
Mon, 11 Sep 2023 21:11:46 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 2FD1C402D6;
Mon, 11 Sep 2023 21:11:46 +0200 (CEST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com
[64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 6E6EA402CE
for <dev@dpdk.org>; Mon, 11 Sep 2023 21:11:44 +0200 (CEST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.west.internal (Postfix) with ESMTP id 6D5DA3200920;
Mon, 11 Sep 2023 15:11:40 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute4.internal (MEProxy); Mon, 11 Sep 2023 15:11:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
cc:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to; s=fm1; t=
1694459499; x=1694545899; bh=ef8jQzm9a54g+GsspZTE0ZLHQROo5Z83MKt
PYNHU0+U=; b=OiQZ4xYGevf+dd1LEMJm8RHHcDt4u1cHKdd8iv1mXBAIACJxmxR
YDLCdXlLA1M63N+8JcyBHVztzd+qErAqEH7D+ZRdx7XqdaGAHA0n8glpCQG8aZNZ
03AVta26euaci9QCUEMaJ5bD6F3Yrd0/JT/IwClp1Q/EJo28pBIQ0DL9qbwInAWD
/GLLa+5Fo+4nGBmRJup4j40QM1fgdsht/2vC8GOu6tZ9usoHZ73kKC4BpKYVu6cQ
ZYIyzwUruqNoG2CEISkKbDnMWLuz62mzGVQCiyevmETtwfZ9EtwpmWe2tZujZPXg
3n4vDOGUq9UQlZ02ZwrlyBW97sm+S/kkkog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
1694459499; x=1694545899; bh=ef8jQzm9a54g+GsspZTE0ZLHQROo5Z83MKt
PYNHU0+U=; b=yoxNiPBe7EgHJ8LvVcUhcxHmSFxAta5IQdcafNvsLSksVJUGW3U
ax7chk1h8X5TniYDUDaYfm4hq34CL5gC8O7myRxy/q93kLYYNQaBe4C8KNhmzbv/
4lgj7Siiac3LlkJlOmWpWNcf6iILPXMbRFhjAeTP2r6nLRMTWRcFT42Yw5aXOtUW
Y916Tt9SpV7rviB8cfOPXqOKIRAh9RkXmSoIRuZlVvKUybd+CsVp6GM9E+El9k+y
Rqq/5P0TmCFe9lizvAUBib0PRKbTym5GHOzS1URTvJjY8pQj8x5TYw4SEnS44lL2
t/WmyJ4Ft7QZ5Kf/Ewql5UKhjaQFlcqlKow==
X-ME-Sender: <xms:a2b_ZFJSUAjyGPqZvzXk6j6nlQnxb5P05s_18BZ9g0LgSWE9g6JfVg>
<xme:a2b_ZBLVtvutRHks89x9ooGGd-M5R-iuAiagpwUA2KKDGTzD3S3x13qB7_ZuI8VWy
I0_HXDw_PiOfy8Hug>
X-ME-Received: <xmr:a2b_ZNs8P3AG0TMvaG_Pp0icrGFWPUMOXqnoLIedrzs39APhuoWvxL4oaaQKJH5n6wDwjLd3qwNqELhCo-lQnBCNx82cI9FxPlHYQw2wdBI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeigedgudefudcutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
enucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhho
mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne
cuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedv
ieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:a2b_ZGYXYeRtEPFh4gdRmGdma6CygiLSfu6siOGB5WRKuNPEHYqOWw>
<xmx:a2b_ZMZeqLqpgrX6C3e2nzZAzClG5W5PQH0za1JuxFKSBTjbaGn6Og>
<xmx:a2b_ZKDaRFLw145UyngeETJZZsvnR9tauzCiQkEdwOm67oMMDo510g>
<xmx:a2b_ZEH0cT3vVlwKmyl_oAdDq40JWVmfIs8OTSkzjn2YLJpDUwySzg>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
11 Sep 2023 15:11:37 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>, dev@dpdk.org,
Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Cc: Tyler Retzlaff <roretzla@linux.microsoft.com>,
Ferruh Yigit <ferruh.yigit@amd.com>
Subject: Re: [PATCH 05/11] eal: force prefix for internal threads
Date: Mon, 11 Sep 2023 18:26:11 +0200
Message-ID: <3082546.U3zVgo479M@thomas>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87B83@smartserver.smartshare.dk>
References: <20230906162226.1618088-1-thomas@monjalon.net>
<CAJFAV8zUcZq6cosc7JOxSsJbM3GnrZe-9M5dOuzRFh_TkQffhw@mail.gmail.com>
<98CBD80474FA8B44BF855DF32C47DC35D87B83@smartserver.smartshare.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
07/09/2023 13:10, Morten Br=C3=B8rup:
> > From: David Marchand [mailto:david.marchand@redhat.com]
> > Sent: Thursday, 7 September 2023 10.55
> >=20
> > On Thu, Sep 7, 2023 at 10:53=E2=80=AFAM David Marchand
> > <david.marchand@redhat.com> wrote:
> > >
> > > On Thu, Sep 7, 2023 at 10:50=E2=80=AFAM Morten Br=C3=B8rup <mb@smarts=
haresystems.com>
> > wrote:
> > > > > This 10 value in the comment is easy to miss if some change with =
the
> > > > > prefix is done.
> > > > > Mentionning RTE_THREAD_INTERNAL_NAME_SIZE is enough.
> > > >
> > > > I disagree with David's comment to this.
> > > >
> > > > The function documentation is easier to read if the actual number i=
s also
> > mentioned.
> > > >
> > > > For the best of both worlds, you can add something like this nearby:
> > > >
> > > > _Static_assert(sizeof(RTE_THREAD_NAME_PREFIX) =3D=3D sizeof("dpdk-"=
),
> > > > "Length of RTE_THREAD_NAME_PREFIX has changed; "
> > > > "the documentation needs updating.");
> > >
> > > And how will it catch the comment about 10 characters ?
> >=20
> > I mean you still have to re-read the whole documentation and look for
> > some reference somewhere about 10 characters.
>=20
> The trick is to put the _Static_assert close to where the expectation occ=
urs. That makes it easier to find where changes are necessary.
>=20
> And the _Static_assert can be added at all the locations where changes wo=
uld be necessary. (Generally, we should add a lot more _Static_assert to th=
e code where it makes assumptions about e.g. the ordering of fields in a st=
ruct, such as the vector optimized code.)
>=20
> Also, the failure message could be improved to include help about what to=
look for.
>=20
> PS: The reference to RTE_THREAD_INTERNAL_NAME_SIZE should remain in the d=
ocumentation, so perhaps look for "RTE_THREAD_INTERNAL_NAME_SIZE".
I agree with David, it is easier to maintain if not mentioning
the exact value in the doc,
and having a mention to RTE_THREAD_INTERNAL_NAME_SIZE is enough
if it defined as "11".
Then we need only one static assert (or RTE_BUILD_BUG_ON)
below the definition to make sure the number is still valid.