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 D4E5F45E83;
Thu, 12 Dec 2024 08:57:54 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 0159C402DE;
Thu, 12 Dec 2024 08:57:52 +0100 (CET)
Received: from us-smtp-delivery-124.mimecast.com
(us-smtp-delivery-124.mimecast.com [170.10.129.124])
by mails.dpdk.org (Postfix) with ESMTP id D2B5D402DE
for <dev@dpdk.org>; Thu, 12 Dec 2024 08:57:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1733990269;
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=AuygHCtBGoWlGAS8lcuPHbCkhHqkFYcCpXKkwACgyFk=;
b=VhwCPzGLsEqm72ROzMd04vguRfFBJgxN7aRFAOFMq26/nkeveO7intwDkTU2/bY6oKSnt1
/GB6eM+1M5H8okjFK51dKsvqVjfqzuov/j4oNeROIzN5Bu00fn8w1NZVPZaVOgvFflXdOM
F5iXJ3j5U6W4QGqyMBfX8tF0hGlA49A=
Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com
[209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-395-L5vOM6AuOJO4QwIdf9LIeg-1; Thu, 12 Dec 2024 02:57:47 -0500
X-MC-Unique: L5vOM6AuOJO4QwIdf9LIeg-1
X-Mimecast-MFC-AGG-ID: L5vOM6AuOJO4QwIdf9LIeg
Received: by mail-lj1-f200.google.com with SMTP id
38308e7fff4ca-301e3d7adceso1177771fa.3
for <dev@dpdk.org>; Wed, 11 Dec 2024 23:57:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1733990266; x=1734595066;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=AuygHCtBGoWlGAS8lcuPHbCkhHqkFYcCpXKkwACgyFk=;
b=aYLnMb/uS/uIJPTJ5dor/Dt/ieugpimVlGRb9Qdfe65SuD85ESL+wDYgYwzVgjw4II
P5C7K0rmvy1yERtuOC5IZE/4H296zOCzncHVysm6TU/zz2JJ0K/KilYlUDJGi0cnPX72
GB2ziRBcGOPYhRtEbyVykvhY0IUh03Ltm4bPmH0TdQnLebs4lGGw446/B/+p29Xv1E/H
BHiyLyOh4ra3HX+NOmKQYP7SDbloK0udmnptvZO0XAky6N3cuGO7mROu9XWCViYBp/cN
W+BRvqNMlgx6vJTOkamvsQ9VGwXCpQNJVA2/uT7zvMMkMYxqqXhb/72iRGfb0JkiWpJ0
8AuQ==
X-Gm-Message-State: AOJu0YwlPjkhXi/2ADFMGCG026QSgbvZBFP1pDC+ZEu7+c5Lhixgf4C/
4PVRBvOXWagovbFifEntFpYRB79n4z1j8sN8U4XwBxyIzTNVF5FCzXBsnzFj2qeHswYFAfJ9pLu
aOjYd/D+HD+RXcxuQoWOX4Oq4fXn/iJITy7Wy4o6wAEbLPvxSm2m1jMmoXiUdbE4pN9j5HVwe8Y
SkGbIKThIdf4hGL2I=
X-Gm-Gg: ASbGnctOBo2uCe5UdwLrchQ2OQj1U5gm5KMhJ+/2LemFu+iW9T1l9JV/l7wUU/OPtXr
bps2LTFbaTbPs8bd5ZIs33Bphu0K6HfT2ZLTSFL69
X-Received: by 2002:a2e:a9a6:0:b0:302:17e7:e176 with SMTP id
38308e7fff4ca-30249dcdce8mr6802511fa.5.1733990266354;
Wed, 11 Dec 2024 23:57:46 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFR0JLHRXxJaYiMcgdQ0iCDU9imysSNF6KDZOe2WwX1KU+9u1z/3ecOETsT9QXSB2h2yp9q9+TDLaWEBjCJzog=
X-Received: by 2002:a2e:a9a6:0:b0:302:17e7:e176 with SMTP id
38308e7fff4ca-30249dcdce8mr6802381fa.5.1733990265963; Wed, 11 Dec 2024
23:57:45 -0800 (PST)
MIME-Version: 1.0
References: <20241205175754.1673888-1-david.marchand@redhat.com>
<20241205175754.1673888-3-david.marchand@redhat.com>
<16f6d334-d999-4fe7-b177-6daf881b8f1e@lysator.liu.se>
In-Reply-To: <16f6d334-d999-4fe7-b177-6daf881b8f1e@lysator.liu.se>
From: David Marchand <david.marchand@redhat.com>
Date: Thu, 12 Dec 2024 08:57:35 +0100
Message-ID: <CAJFAV8z2pCU+uk=Sv6Cpvt1_JBHjfV2zrNHWGCa5uEw1oohvjQ@mail.gmail.com>
Subject: Re: [PATCH 2/3] power: defer lcore variable allocation
To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <hofors@lysator.liu.se>
Cc: dev@dpdk.org, thomas@monjalon.net, frode.nordahl@canonical.com,
mattias.ronnblom@ericsson.com, stable@dpdk.org,
Anatoly Burakov <anatoly.burakov@intel.com>, David Hunt <david.hunt@intel.com>,
Sivaprasad Tummala <sivaprasad.tummala@amd.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Chengwen Feng <fengchengwen@huawei.com>,
Konstantin Ananyev <konstantin.ananyev@huawei.com>,
=?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: IAiyr-VOR_RIzkiOiiE8XlY2eTkuuMCdVft8Kg6aS24_1733990266
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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
On Fri, Dec 6, 2024 at 12:29=E2=80=AFPM Mattias R=C3=B6nnblom <hofors@lysat=
or.liu.se> wrote:
> I would wrap all RTE_LCORE_VAR_LCORE() and RTE_LCORE_VAR().
>
> static struct pmd_core_cfg *
> get_cfg_lcore(unsigned int lcore_id)
> {
> assure_lcore_cfgs_alloced();
> return RTE_LCORE_VAR_LCORE(lcore_cfgs, lcore_id);
> }
>
> static struct pmd_core_cfg *
> get_cfg(void)
> {
> get_cfg_lcore(rte_lcore_id());
> }
>
> Add
>
> static void
> assure_lcore_cfgs_alloced(unsigned int lcore_id)
> {
> if (lcore_cfgs !=3D NULL)
=3D=3D
> lcore_cfgs_alloc();
> }
>
> ..or maybe better merge assure_lcore_cfgs_alloced() and lcore_cfgs_alloc(=
).
>
> Makes it a little harder to make mistakes.
clb_multiwait, clb_pause and clb_scale_freq callbacks can only be
reached after a successful call to
rte_power_ethdev_pmgmt_queue_enable.
Triggering an allocation in them means we are hiding a (internal)
programatic error as allocation and use of a lcore variable are
clearly separated atm.
If we keep the lcore var api as is, I would add an assert() (maybe
under a debug build option) in RTE_LCORE_VAR macros themselves, as
calling with a NULL handle means the initialisation path in some
code/RTE_LCORE_VAR API use was incorrect.
Or because you propose to add the same type of helpers in both this
patch and the next, I am considering the other way: hide the
allocation in the RTE_LCORE_VAR* macros.
Checking for already allocated var in RTE_LCORE_VAR_ALLOC seems fine.
But the "fast path" RTE_LCORE_VAR would have an unwanted branch in most cas=
es.
> A somewhat unrelated question: why is pmd_core_cfg cache-line aligned? I
> don't think it should be.
Before the conversion to per lcore variable, it was probably useful
(avoiding false sharing).
With the conversion, indeed, it looks like a waste of space.
It seems worth a separate fix.
--=20
David Marchand