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 529FFA04B5; Tue, 12 Jan 2021 17:03:52 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D931B140E51; Tue, 12 Jan 2021 17:03:51 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id F2F46140E47 for ; Tue, 12 Jan 2021 17:03:49 +0100 (CET) IronPort-SDR: OyIFW+g3ucvSHLcbYcEG61JTyTVBRL2z9ZF5u0rdyBCzXqrKzm1rjPiAK64kgbgyXGEPlBo4k8 FbZbElNrh54Q== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="196683938" X-IronPort-AV: E=Sophos;i="5.79,341,1602572400"; d="scan'208";a="196683938" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 08:03:06 -0800 IronPort-SDR: 3iYXwonx2zTE/oeF0/IN6ilFLx1+QLGKX/6iV4Lw3lQSRNmb90cTDuINvDb2CktA1n/VwChY0d 6KMy8KgMbh2Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,341,1602572400"; d="scan'208";a="400217616" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga002.fm.intel.com with ESMTP; 12 Jan 2021 08:03:02 -0800 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 12 Jan 2021 08:02:57 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 12 Jan 2021 08:02:57 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 12 Jan 2021 08:02:57 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.105) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 12 Jan 2021 08:02:51 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KD1Qw2+7zB6JVJU3PlMHSxVBw9DFJT2QE/m0I3y6/ocI74cfzCQyYdOqTRWKRJW2vgtWh4B1CuIM0KamVxA8xIulmPdHFVEqlrCRN7sfG2xub7VkCNiQu+wVI/1skLLdgQNQmWWemvZG+yWG0m80jGwmH7nkovfiQG6XO2pFVQCmCTk4CfMckSFEkKxzlF+6XvvNq9YNcHPOwQLeh+wWOHcHo10+6HuqPRfPbrH0S/UCqytVnW+fsLdb/KaQJgIyJ+ehdrDyKNJWGrUvIRpewjaL/7QZxzZ6GP4qSShCwregIvQHhD1f7JGpc7UfWYU9Y3OicQed0CBL4jvlsfUWcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J5lprDMSv1PSXMdekQpEI/Hnm771SMNewaEorfCIgZw=; b=BUnS/7VosJIVBrsuPbAQlIpyFMijukNacYkkC/FFBSR4FgRLwGA2Aq3she+lkdrKTH4Mn7RGCNaCkSR9q0j2PH/hLEXkD7Rs0syagm67++odWVkTRHPBSjH8aZNx/+/erjtkYGJHtmZtVc1hDsuNBKLNPlYyOQeWjMVyKa4u+vjmFTGFXymXnDp3Xs2rHSGG3gwfZmPfxaWMopHcMAIz3nZtJvSX41ymbK7MouD9zmsmukDUV7MmbdsWWw+8/m7nUkjhZ64Wl8fP70VtpE2zOwzDrtqkQSqcwoasH0OnOb/NHyu3D3YFuWHbomSG0GSIriTniyg5DyQVMjq/lIMCYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J5lprDMSv1PSXMdekQpEI/Hnm771SMNewaEorfCIgZw=; b=SIWvlQaNukhz/307zz+Zagbg92wjrLdC7x3vPnldMhGMtENLASVLFpvHjyz5wBYox1OzvmPn2fL5T9SB/ym9o1RXd73A6fyMI7hLfdMDw7EGfsaBHv1G8crXgR9xzHqEZRYWNelk5ckMW3P851wGeh6PoBwBt118JDJeC9O5SUE= Received: from BYAPR11MB3301.namprd11.prod.outlook.com (2603:10b6:a03:7f::26) by BYAPR11MB2920.namprd11.prod.outlook.com (2603:10b6:a03:82::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Tue, 12 Jan 2021 16:02:47 +0000 Received: from BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::1152:1426:8a4f:c755]) by BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::1152:1426:8a4f:c755%4]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 16:02:47 +0000 From: "Ananyev, Konstantin" To: "Burakov, Anatoly" , "dev@dpdk.org" CC: Jan Viktorin , Ruifeng Wang , Jerin Jacob , David Christensen , Ray Kinsella , Neil Horman , "Richardson, Bruce" , "thomas@monjalon.net" , "gage.eads@intel.com" , "McDaniel, Timothy" , "Hunt, David" , "Macnamara, Chris" Thread-Topic: [PATCH v13 05/11] eal: add monitor wakeup function Thread-Index: AQHW5eWpl3hTMSr2XUOx5QqCkBEG2qokLCnA Date: Tue, 12 Jan 2021 16:02:47 +0000 Message-ID: References: <0265c6b23e59f089e7f03a48e8904ae410639868.1610127362.git.anatoly.burakov@intel.com> In-Reply-To: <0265c6b23e59f089e7f03a48e8904ae410639868.1610127362.git.anatoly.burakov@intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [46.7.39.127] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e9ee867-0311-4e04-1d49-08d8b7138185 x-ms-traffictypediagnostic: BYAPR11MB2920: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IhPQoiBsF/0BHr0dvGQQ6R3qkLhA1ODvAfaTGOuZQXOhdEJ+dZlamfVU7SVlI2Se2mv0rHWKFNxspFVFjhS9D0Vx1VZmrndyEMfPnAQ/KVakk2d1VoPmGSh3CNVCZFugGCt+k7UvigkxrDbLfVksBp5UrMExK2cgYhTt2pP9efdQivVOKIusNfexQVmbbMs8FdGSxPvM3fqTmr4j/Oqi4BpE50S6BQR9+63ZNTTZA2HypomDw838SHh2S1rIn4sP8WDV9M/Yc/+B2qnJVEP+Tq16oaxwIFoHj5/Skvel49JCfk7QPgwAyFFFycF6wahCKZgNL7eZTkmL3voQQJkuOK2L58tvwssz8ptX5xtK4lgjeAaxfEB4HbqNjKhat4D6qrfQy7WaoOqWJynByNIwTg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3301.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(366004)(39860400002)(376002)(107886003)(7696005)(66476007)(110136005)(76116006)(6506007)(66556008)(66946007)(54906003)(66446008)(64756008)(8936002)(8676002)(4326008)(71200400001)(33656002)(316002)(478600001)(86362001)(26005)(186003)(52536014)(83380400001)(55016002)(2906002)(5660300002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?6COgV6OYpByieN9QekoRPtmyG4EW9HO0Dp0xcA0C9g/8hYmOel48arpezKWK?= =?us-ascii?Q?Lqjxnz3ubRCvcLjYvG044WnB5ZZjF81YYmGu7hivsfEC/b8HZ54rd95eYc4T?= =?us-ascii?Q?Mt+ZJKCqplWfwEowClCkvMBlNYGc1SkUdKOGdkGx0L32ROzCrmgCLu4zwZyg?= =?us-ascii?Q?kMIC9jMa94S8+2lGzZaoMytKa6BdzTzVAZBrE5G2xS0ukBuubPn1TFelZZBl?= =?us-ascii?Q?+swi/eFnGwtB5sNEpXduZcFMlPniQcUZs22MP26Ioau6mVCVMDy8z+QHeaOe?= =?us-ascii?Q?9R4Z192n+8W8/GjgE8OfTKAiTfwnborRLo7kI0sisMz4AW/m+kYqOhsKjkK8?= =?us-ascii?Q?InByDV8ScYtg6AIimChwkdyoQjlnWqRIa5AQgfzncgxdHMQtVl0oejNgNNcO?= =?us-ascii?Q?+gDX4pCF5VRz+gqEeshxHNh1qdLhjnHrEexvb7K9R93es29gBsv/p+pI8UqA?= =?us-ascii?Q?KcP3pzBwdAmA0meFYmMkt+TyOXeTAX3GryaCbAjQdm7gn0FpOHTLBGDr8Ff2?= =?us-ascii?Q?w2BhOsibM6pwVHj9OQNfUJ9fcyLhCr+/rTqE1DGBlpA6+DXRH/e3lC1knv6a?= =?us-ascii?Q?wKlw9zOY+w3cOCbhOWmWCduhQGdLQuvcOa8A3MRXGMsXKgz/nAa71/d7t5hH?= =?us-ascii?Q?wjO4NMpuAjVko9d4fYcAsaRe7ty6QEb7MtAI8K3q2fv9pXwq20jSYtJ8Jyam?= =?us-ascii?Q?Z/jCXLMpNnMmu0ySMFw/jtxO4Xbm1PDqCveKCv75GG+jihIpFmVgIh/FfJec?= =?us-ascii?Q?W6MbO6uZf2TlI+iPP0eFUN+CQ5xgkZXatMd7lHyYXg6vVZQk7NKQvTTmHQRA?= =?us-ascii?Q?hIK0kJ4gLOYD8sStErYHB9jEBAnr5bxLIt+sPGG/+ZAMSzhzZ1f969EOR0jB?= =?us-ascii?Q?z/81tGVPjpZZnAPX1mcSeTk4OqBkUS3RVUh4sjcIRfK3slqNMI02G7sQw/yI?= =?us-ascii?Q?P5mlrFkEkv4810BRoK3RQra1qGIgHBVDmkyhv2YAJ/U=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3301.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e9ee867-0311-4e04-1d49-08d8b7138185 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 16:02:47.6792 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7otO3zORQPlq1hQHbstDdzRGKeWMqu/zAgC06IQ9sE0ta3WhoOHwcKEJtx16BQhaALt81i/I3NLGZzAQp2/zxEFSxhgPJ1am6wso0qRjq7A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2920 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v13 05/11] eal: add monitor wakeup function X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >=20 > Now that we have everything in a C file, we can store the information > about our sleep, and have a native mechanism to wake up the sleeping > core. This mechanism would however only wake up a core that's sleeping > while monitoring - waking up from `rte_power_pause` won't work. >=20 > Signed-off-by: Anatoly Burakov > --- >=20 > Notes: > v13: > - Add comments around wakeup code to explain what it does > - Add lcore_id parameter checking to prevent buffer overrun >=20 > .../arm/include/rte_power_intrinsics.h | 9 ++ > .../include/generic/rte_power_intrinsics.h | 16 ++++ > .../ppc/include/rte_power_intrinsics.h | 9 ++ > lib/librte_eal/version.map | 1 + > lib/librte_eal/x86/rte_power_intrinsics.c | 85 +++++++++++++++++++ > 5 files changed, 120 insertions(+) >=20 > diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h b/lib/libr= te_eal/arm/include/rte_power_intrinsics.h > index 27869251a8..39e49cc45b 100644 > --- a/lib/librte_eal/arm/include/rte_power_intrinsics.h > +++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h > @@ -33,6 +33,15 @@ rte_power_pause(const uint64_t tsc_timestamp) > RTE_SET_USED(tsc_timestamp); > } >=20 > +/** > + * This function is not supported on ARM. > + */ > +void > +rte_power_monitor_wakeup(const unsigned int lcore_id) > +{ > + RTE_SET_USED(lcore_id); > +} > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/= librte_eal/include/generic/rte_power_intrinsics.h > index a6f1955996..e311d6f8ea 100644 > --- a/lib/librte_eal/include/generic/rte_power_intrinsics.h > +++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h > @@ -57,6 +57,22 @@ __rte_experimental > void rte_power_monitor(const struct rte_power_monitor_cond *pmc, > const uint64_t tsc_timestamp); >=20 > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice > + * > + * Wake up a specific lcore that is in a power optimized state and is mo= nitoring > + * an address. > + * > + * @note This function will *not* wake up a core that is in a power opti= mized > + * state due to calling `rte_power_pause`. > + * > + * @param lcore_id > + * Lcore ID of a sleeping thread. > + */ > +__rte_experimental > +void rte_power_monitor_wakeup(const unsigned int lcore_id); > + > /** > * @warning > * @b EXPERIMENTAL: this API may change without prior notice > diff --git a/lib/librte_eal/ppc/include/rte_power_intrinsics.h b/lib/libr= te_eal/ppc/include/rte_power_intrinsics.h > index 248d1f4a23..2e7db0e7eb 100644 > --- a/lib/librte_eal/ppc/include/rte_power_intrinsics.h > +++ b/lib/librte_eal/ppc/include/rte_power_intrinsics.h > @@ -33,6 +33,15 @@ rte_power_pause(const uint64_t tsc_timestamp) > RTE_SET_USED(tsc_timestamp); > } >=20 > +/** > + * This function is not supported on PPC64. > + */ > +void > +rte_power_monitor_wakeup(const unsigned int lcore_id) > +{ > + RTE_SET_USED(lcore_id); > +} > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map > index 20945b1efa..ac026e289d 100644 > --- a/lib/librte_eal/version.map > +++ b/lib/librte_eal/version.map > @@ -406,6 +406,7 @@ EXPERIMENTAL { >=20 > # added in 21.02 > rte_power_monitor; > + rte_power_monitor_wakeup; > rte_power_pause; > }; >=20 > diff --git a/lib/librte_eal/x86/rte_power_intrinsics.c b/lib/librte_eal/x= 86/rte_power_intrinsics.c > index a9cd1afe9d..46a4fb6cd5 100644 > --- a/lib/librte_eal/x86/rte_power_intrinsics.c > +++ b/lib/librte_eal/x86/rte_power_intrinsics.c > @@ -2,8 +2,31 @@ > * Copyright(c) 2020 Intel Corporation > */ >=20 > +#include > +#include > +#include > + > #include "rte_power_intrinsics.h" >=20 > +/* > + * Per-lcore structure holding current status of C0.2 sleeps. > + */ > +static struct power_wait_status { > + rte_spinlock_t lock; > + volatile void *monitor_addr; /**< NULL if not currently sleeping */ > +} __rte_cache_aligned wait_status[RTE_MAX_LCORE]; > + > +static inline void > +__umwait_wakeup(volatile void *addr) > +{ > + uint64_t val; > + > + /* trigger a write but don't change the value */ > + val =3D __atomic_load_n((volatile uint64_t *)addr, __ATOMIC_RELAXED); > + __atomic_compare_exchange_n((volatile uint64_t *)addr, &val, val, 0, > + __ATOMIC_RELAXED, __ATOMIC_RELAXED); > +} > + > static uint8_t wait_supported; >=20 > static inline uint64_t > @@ -36,6 +59,12 @@ rte_power_monitor(const struct rte_power_monitor_cond = *pmc, > { > const uint32_t tsc_l =3D (uint32_t)tsc_timestamp; > const uint32_t tsc_h =3D (uint32_t)(tsc_timestamp >> 32); > + const unsigned int lcore_id =3D rte_lcore_id(); > + struct power_wait_status *s; > + > + /* prevent non-EAL thread from using this API */ > + if (lcore_id >=3D RTE_MAX_LCORE) > + return; >=20 > /* prevent user from running this instruction if it's not supported */ > if (!wait_supported) > @@ -60,11 +89,24 @@ rte_power_monitor(const struct rte_power_monitor_cond= *pmc, > if (masked =3D=3D pmc->val) > return; > } > + > + s =3D &wait_status[lcore_id]; > + > + /* update sleep address */ > + rte_spinlock_lock(&s->lock); > + s->monitor_addr =3D pmc->addr; > + rte_spinlock_unlock(&s->lock); It was a while, since I looked at it last time, but shouldn't we grab the lock before monitor()? I.E: lock(); monitor(); addr=3D...; unlock(); umwait(); > + > /* execute UMWAIT */ > asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;" > : /* ignore rflags */ > : "D"(0), /* enter C0.2 */ > "a"(tsc_l), "d"(tsc_h)); > + > + /* erase sleep address */ > + rte_spinlock_lock(&s->lock); > + s->monitor_addr =3D NULL; > + rte_spinlock_unlock(&s->lock); > } >=20 > /** > @@ -97,3 +139,46 @@ RTE_INIT(rte_power_intrinsics_init) { > if (i.power_monitor && i.power_pause) > wait_supported =3D 1; > } > + > +void > +rte_power_monitor_wakeup(const unsigned int lcore_id) > +{ > + struct power_wait_status *s; > + > + /* prevent buffer overrun */ > + if (lcore_id >=3D RTE_MAX_LCORE) > + return; > + > + /* prevent user from running this instruction if it's not supported */ > + if (!wait_supported) > + return; > + > + s =3D &wait_status[lcore_id]; > + > + /* > + * There is a race condition between sleep, wakeup and locking, but we > + * don't need to handle it. > + * > + * Possible situations: > + * > + * 1. T1 locks, sets address, unlocks > + * 2. T2 locks, triggers wakeup, unlocks > + * 3. T1 sleeps > + * > + * In this case, because T1 has already set the address for monitoring, > + * we will wake up immediately even if T2 triggers wakeup before T1 > + * goes to sleep. > + * > + * 1. T1 locks, sets address, unlocks, goes to sleep, and wakes up > + * 2. T2 locks, triggers wakeup, and unlocks > + * 3. T1 locks, erases address, and unlocks > + * > + * In this case, since we've already woken up, the "wakeup" was > + * unneeded, and since T1 is still waiting on T2 releasing the lock, th= e > + * wakeup address is still valid so it's perfectly safe to write it. > + */ > + rte_spinlock_lock(&s->lock); > + if (s->monitor_addr !=3D NULL) > + __umwait_wakeup(s->monitor_addr); > + rte_spinlock_unlock(&s->lock); > +} > -- > 2.25.1