From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CFF5545E82 for ; 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 0D849402EF; Thu, 12 Dec 2024 08:57:53 +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 CF35840269 for ; 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-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-489-WcCfHv55PQWqY3nnDopSag-1; Thu, 12 Dec 2024 02:57:47 -0500 X-MC-Unique: WcCfHv55PQWqY3nnDopSag-1 X-Mimecast-MFC-AGG-ID: WcCfHv55PQWqY3nnDopSag Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-30036354518so1032891fa.2 for ; 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=urpGwlrUY3rwhL+9F4EQQW0XqveYTH9Mz2MIoBf96l0DQa9Rqz6pRUFjge6MxH40X6 M7yPBSFJw70t6l6a3sZYxkoYZBZZzhZaPis6YJB1QPJNyQJtEkHh67Zu4oX5ITGVAEtG D1dpaHbBRyOqL06X5QInfVDUpzslAVB4d99o8CJvJyMAE42rwvtGmEhhaUqUlivtIegH NUADYgIroS4Xd0iCLQeRqpiknBlzjmMPGx7ulNLWgmEW39R3EGkrEAqeCw17zyCq1VQI y5CJmneP6kFBFoO8/s+wTckWZ4W+9sIRaAs8UpeEbK2a21REZA4t5f07XcPo673XApWj 3NXw== X-Forwarded-Encrypted: i=1; AJvYcCU6qTC9L171EKbT9A315wE1C/UN9qY9sFJXOu4r19kLY3sOBLXqMGN+cTgE6rpGO0MhOHlsisg=@dpdk.org X-Gm-Message-State: AOJu0Yxly4/dxpQmtAkX4B6yg2al/fHicF+C/iauXbGqjyAXZSMDaPc9 27I2QKWkPZQrBOXYHctuxCmoY310BEm1Qu1InxdyxQNvK/+q81YcmBmyYTBRlwakedy1VTHB58X Os1TH1h+Vh2veekmS29wF0MP3Lt5jKbl6w3GR/inMWELuMdWmvxx7Ih11PZhZ9edz3HuV5H+YHC QhvXfodV41uOxxwt99Fxk= X-Gm-Gg: ASbGncvJUHBUn76Kd0iikcjRnDjsRWGVO6MVQeIdFQCG0inAbdTd6zeMrC0kHvbmKuK RUNSzz2VTGKy5uMTE13DFrMG2gyjTO2MgOu3lFI6z X-Received: by 2002:a2e:a9a6:0:b0:302:17e7:e176 with SMTP id 38308e7fff4ca-30249dcdce8mr6802481fa.5.1733990266353; 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 Date: Thu, 12 Dec 2024 08:57:35 +0100 Message-ID: Subject: Re: [PATCH 2/3] power: defer lcore variable allocation To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: dev@dpdk.org, thomas@monjalon.net, frode.nordahl@canonical.com, mattias.ronnblom@ericsson.com, stable@dpdk.org, Anatoly Burakov , David Hunt , Sivaprasad Tummala , Stephen Hemminger , Chengwen Feng , Konstantin Ananyev , =?UTF-8?Q?Morten_Br=C3=B8rup?= X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: xwEQfQ4UaSLvLiXDi8blb_5XgUw2OGI8NAl3upvKlJQ_1733990266 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Fri, Dec 6, 2024 at 12:29=E2=80=AFPM Mattias R=C3=B6nnblom 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