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 2ACF3A0C3F; Mon, 28 Jun 2021 14:37:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9BA5240692; Mon, 28 Jun 2021 14:37:39 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id DE9954068A for ; Mon, 28 Jun 2021 14:37:37 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10028"; a="269072864" X-IronPort-AV: E=Sophos;i="5.83,306,1616482800"; d="scan'208";a="269072864" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 05:37:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,306,1616482800"; d="scan'208";a="625238906" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga005.jf.intel.com with ESMTP; 28 Jun 2021 05:37:20 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Mon, 28 Jun 2021 05:37:20 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) 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.2242.4; Mon, 28 Jun 2021 05:37:19 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) 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.2242.4 via Frontend Transport; Mon, 28 Jun 2021 05:37:19 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Mon, 28 Jun 2021 05:37:19 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a+RgpQCJxQLUJgy46MxSkpo95Z5k3gVk2JRCHEZN1SBYeDhDh89G1I1APmK4BWRsAuqryMJUwwpJNOIXMmkJrv41DVhGvtxIvrK4Ln+AsR7yh577OyN9tH62a1EGS4VwxmP8m0YULKpwpoSHY6bEEa6SV5BEx75bkkD0BBYPX1w5ME9Uqoz3w4WpI9d7UK9267CMxdNGt60wbeeCC7O0Y+P9Z/kP2DFTO5AXTwUtMLsIMPh3mZGpnx08hk388StwC0c7w/atUaKdemkBDUUi8ru09NnMGMVdjNCS806rtfgRSekSjhuE+CP04W825SywhBU0FPxcsmSGIrzHiRcIJg== 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=gQ5XHiNpHXQeSfNaVhGiChyEfzqRCX3MOECIwp6a5Dw=; b=jzRR2PtQymJGTCzZSEzekvjAGCgHmpQHPSMB4esc2rwY5EbrSa8tk94oRZBfRdoXCSb+7gW+EdH1xUZ9XBgi/YSB2uMgOSDh8EZdLRIWxtpK5qf3j4DNMAjLu+PA08p/Fmvuvh/9zaI5rZ4tKlbl3ZWGnOTuUVrIDBk1UksFZS9gOtGPr8y61oKWrrKxMFbp1V2Pp2WQ+y+tsbR8YNbg8usm0uz9ZV19ylhSLrOxxTdbNryRwijoGfogL/l9xyM9XcEYDesNVxT7QbG0UGau47TaS1s8hj2aWUJ1BTyBFLDZroc2Lnkivh6Nvjt4ihF6XNR+mfk+WAkjo/H5hoEn/Q== 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=gQ5XHiNpHXQeSfNaVhGiChyEfzqRCX3MOECIwp6a5Dw=; b=z0z0idv6ITd0obvkaTrEULpTZ0AML9Fu3mTZd2GZGncN1EMPuGujFhgpN+ESTKvRathUkJ2arCqoRNHsJiIx1DkyshPN4Z4JK4wuPgueOH4/eIOfueRPK9eWPKD5c5LxalAOHHqbDE/qi1Amp04lOz7cAGp5EFAZTqcbPbbSepQ= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM5PR11MB1818.namprd11.prod.outlook.com (2603:10b6:3:114::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.23; Mon, 28 Jun 2021 12:37:17 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7dc4:66b0:f76b:6d48]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7dc4:66b0:f76b:6d48%7]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 12:37:17 +0000 From: "Ananyev, Konstantin" To: "Burakov, Anatoly" , "dev@dpdk.org" , Jerin Jacob , Ruifeng Wang , Jan Viktorin , "David Christensen" , Ray Kinsella , "Neil Horman" , "Richardson, Bruce" CC: "Hunt, David" , "Loftus, Ciara" Thread-Topic: [PATCH v2 3/7] eal: add power monitor for multiple events Thread-Index: AQHXacqAl3nedUSI2kCqojCdgz6KFaspXZEw Date: Mon, 28 Jun 2021 12:37:17 +0000 Message-ID: References: <6c48562add728df4e2f22b3a41170d624c63e233.1624629506.git.anatoly.burakov@intel.com> In-Reply-To: <6c48562add728df4e2f22b3a41170d624c63e233.1624629506.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: [109.255.184.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a3797a89-147c-4546-9700-08d93a317717 x-ms-traffictypediagnostic: DM5PR11MB1818: 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:2887; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C6rj6hgPXpl7o031zY8S17t5Uqp2Onwb5ENTTlkXzxAsfMdXOkZJt6UhjP/Q5bksL7kX04XEfAxiOadJVqyKppgkx5tDIsVkPWIf18210GKaMuskLDEsXfs8f70S20ABGBUiDmtQlnvsmiqTqt/MbTSEnX1IAvK25ORWKqsTGOQvyEnR7Bec/u2TG0A+gwu38pMwHQ6xCG6Moj8vhggrzq8vYjKlHoCYkkPgKaQOv1qff9JaAxltNRvHitKWQW1zrnqDGOa421P9QuXmxpKQvxwt2uSUgW/VetPmJLbQAceNj7jcJCjv1XTNpsGSgj9Djusf+/XrSHt/pj+8TIWyp/7pkXfz7Ykbc2MqNvuDcEQrzC/XJNG0tDmxnkXfBPgPdMxFlrzx4QLvvkbsHr85hJXPak/+8jtPnVBoN0TuWaloYRWpnZ4onsXtpiV2xI8sAypCzpAeu3JdoY6qhUOyt184msc6Mv0VsiAJTCPN2MYXy9HQ2gEmlBgxBhHkTbMef4k0Hd0HaMCes1/E7OmVgzBKxPDWGM4R1y9lhUdki8D5xpbkEISjRHiDclvV9VXgePXuNWPagSNlLRlIM3ktAcuqaCVYuZz2avZ4r5UL3HGiddqCWci7HfyLFmYUnZrZQJmr3tHYWcyXwJHy/kCegLxvL6nkhKanN7Ycvi9yvdh6M7MFU8BAqR+xMAIyqY44y9P4O1nbItZWgZnKUO/WVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(136003)(366004)(376002)(396003)(76116006)(9686003)(6506007)(38100700002)(26005)(8936002)(8676002)(4326008)(66476007)(66556008)(66446008)(66946007)(921005)(64756008)(122000001)(478600001)(55236004)(6636002)(186003)(55016002)(83380400001)(2906002)(52536014)(86362001)(5660300002)(71200400001)(316002)(33656002)(7696005)(110136005)(54906003)(107886003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gwslynfCHuaRjcJqeS3M2z/OxBDx4ugWq9mVTw+FYpVGW0YCIPPtzm0vxJmx?= =?us-ascii?Q?t5r4cNcFFEGtU0/csDpFAvRPbbBorlHkmi2rsEK0B1ir63LNX9ajqwQdC2i0?= =?us-ascii?Q?ADA+fbiIx99lBFGaD9zk829RD279TT1aR5sRxsiLAcT7T4axAEdmKW7DGPhP?= =?us-ascii?Q?5aEMV+UqrGX6LPSNsKA0n8gm5bUDkrJ4EoyWP9kaioHVRYCx9IZeN6SXe1mt?= =?us-ascii?Q?F2RRVGRT9gTO7Jrw6V5pKTV2mLXdoOI7lkjE4guvS4aerywyx8R/oIHda+CU?= =?us-ascii?Q?IxDq9FsOdl2ggRLVrhoFEyQIpyVwOVhPeC5SNpgGkPDtJoyNB1xhdXYi1ovl?= =?us-ascii?Q?fLS+kB/FTYViYueq242Zful2XQB/iup7ujexktIftvbFzLd2jQD9XpvvcdsV?= =?us-ascii?Q?fj9ioWkkxlu14RrfDMfPIpkd5aMrTglA5rNHyCOJX7mv2T13ZShUYpQ3mZO0?= =?us-ascii?Q?cp5yc/KcEnFWmrILz3poC/6xnJWBMNChzJCbynMxU3+kxK6Q9XzxMcSXE4rs?= =?us-ascii?Q?szWeYZD8OPtMqMirgfuoiXYnlnpCvTJ9ieH9Ige5m3sObnB6PFuIGIwC/dib?= =?us-ascii?Q?aP1+aabrRHHM+2Tdj0qzu3Uv/sVtj2Xwk1Uo1cWPJYAPGwJs8ydfhyrDhR7B?= =?us-ascii?Q?8TxI4W+/+A6Hb4+7xCZfHEkkTWdsQC8dvRxtoNYxEHemC/WQt8iiZtSrdzSV?= =?us-ascii?Q?SV8vJURRTwwUYnNsacpJHdjAGVVm3XXdSzN8eK++IRd+TOEMaskXWyowq/Ru?= =?us-ascii?Q?zaeXFoHR+rMwS9bGWFW7tG/1DZILFoMFi2Ic3LVdtWmkUlIpDL9Im0bbF5hS?= =?us-ascii?Q?wlWdDXK6J062vpc70QSOBYSNwBR5D+v0au+U0bn/xccX1zLbGwj/Yb3or6Nj?= =?us-ascii?Q?QLJI2i63whcxX74gMxcywbNgGmsIIQGbGpa8qgd66+q8Zrz1dZ+EEv5aKGLY?= =?us-ascii?Q?aFsDRxO6ANacCwITDEEM7BVCmaBe+VJkEalBPmSk3FljPyiQpfC7K209f7xS?= =?us-ascii?Q?D7Q/wZHXvu72TYlMZf3LJWEGleaZmf8uTTEugKcv+uUQyUxRb+xC9UjSd1Yi?= =?us-ascii?Q?QENDXHNiOkfOtUqFZ1CbZ11wr6cC9/Mu3P8TshzJcfTghH2htZkSMizDrUpS?= =?us-ascii?Q?JcNSuDVljcy50trIwUKMucrNKEBnKy1WT7myDiwzdsU2136ZVdQeBFvPmZBF?= =?us-ascii?Q?ZjPDR8FPwI7Kuf/tbXSc2RkQxEVPz0LEjS3234EJN6BOaoT8FOsiqcyChCFx?= =?us-ascii?Q?F0PzUqhk4mL9GAvZuGLC2jecTKM6k0Ulh0COfxGmMOlFyfcOPRX1IGhS6VuS?= =?us-ascii?Q?3CFRskLswLeQaVyfc+mlxfPq?= 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: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3797a89-147c-4546-9700-08d93a317717 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 12:37:17.4009 (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: GcFPlp29832SSbTZxhEYjGSr5/V7G2c8W/nUXuGEkb9QWASDN61PajxiNPa4MY6D499hbw0j9b59cjEuSKek7dIJ6W4u8pC0SEPze4oan54= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1818 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2 3/7] eal: add power monitor for multiple events 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" > Use RTM and WAITPKG instructions to perform a wait-for-writes similar to > what UMWAIT does, but without the limitation of having to listen for > just one event. This works because the optimized power state used by the > TPAUSE instruction will cause a wake up on RTM transaction abort, so if > we add the addresses we're interested in to the read-set, any write to > those addresses will wake us up. >=20 > Signed-off-by: Konstantin Ananyev > Signed-off-by: Anatoly Burakov > --- >=20 > Notes: > v2: > - Adapt to callback mechanism >=20 > doc/guides/rel_notes/release_21_08.rst | 2 + > lib/eal/arm/rte_power_intrinsics.c | 11 +++ > lib/eal/include/generic/rte_cpuflags.h | 2 + > .../include/generic/rte_power_intrinsics.h | 35 ++++++++++ > lib/eal/ppc/rte_power_intrinsics.c | 11 +++ > lib/eal/version.map | 3 + > lib/eal/x86/rte_cpuflags.c | 2 + > lib/eal/x86/rte_power_intrinsics.c | 69 +++++++++++++++++++ > 8 files changed, 135 insertions(+) >=20 ... > diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_i= ntrinsics.c > index 3c5c9ce7ad..3fc6f62ef5 100644 > --- a/lib/eal/x86/rte_power_intrinsics.c > +++ b/lib/eal/x86/rte_power_intrinsics.c > @@ -4,6 +4,7 @@ >=20 > #include > #include > +#include > #include >=20 > #include "rte_power_intrinsics.h" > @@ -28,6 +29,7 @@ __umwait_wakeup(volatile void *addr) > } >=20 > static bool wait_supported; > +static bool wait_multi_supported; >=20 > static inline uint64_t > __get_umwait_val(const volatile void *p, const uint8_t sz) > @@ -164,6 +166,8 @@ RTE_INIT(rte_power_intrinsics_init) { >=20 > if (i.power_monitor && i.power_pause) > wait_supported =3D 1; > + if (i.power_monitor_multi) > + wait_multi_supported =3D 1; > } >=20 > int > @@ -202,6 +206,9 @@ rte_power_monitor_wakeup(const unsigned int lcore_id) > * 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. > + * > + * For multi-monitor case, the act of locking will in itself trigger th= e > + * wakeup, so no additional writes necessary. > */ > rte_spinlock_lock(&s->lock); > if (s->monitor_addr !=3D NULL) > @@ -210,3 +217,65 @@ rte_power_monitor_wakeup(const unsigned int lcore_id= ) >=20 > return 0; > } > + > +int > +rte_power_monitor_multi(const struct rte_power_monitor_cond pmc[], > + const uint32_t num, const uint64_t tsc_timestamp) > +{ > + const unsigned int lcore_id =3D rte_lcore_id(); > + struct power_wait_status *s =3D &wait_status[lcore_id]; > + uint32_t i, rc; > + > + /* check if supported */ > + if (!wait_multi_supported) > + return -ENOTSUP; > + > + if (pmc =3D=3D NULL || num =3D=3D 0) > + return -EINVAL; > + > + /* we are already inside transaction region, return */ > + if (rte_xtest() !=3D 0) > + return 0; > + > + /* start new transaction region */ > + rc =3D rte_xbegin(); > + > + /* transaction abort, possible write to one of wait addresses */ > + if (rc !=3D RTE_XBEGIN_STARTED) > + return 0; > + > + /* > + * the mere act of reading the lock status here adds the lock to > + * the read set. This means that when we trigger a wakeup from another > + * thread, even if we don't have a defined wakeup address and thus don'= t > + * actually cause any writes, the act of locking our lock will itself > + * trigger the wakeup and abort the transaction. > + */ > + rte_spinlock_is_locked(&s->lock); > + > + /* > + * add all addresses to wait on into transaction read-set and check if > + * any of wakeup conditions are already met. > + */ > + for (i =3D 0; i < num; i++) { > + const struct rte_power_monitor_cond *c =3D &pmc[i]; > + > + if (pmc->fn =3D=3D NULL) Should be c->fn, I believe. > + continue; Actually that way, if c->fn =3D=3D NULL, we'll never add our c->addr to mo= nitored addresses. Is that what we really want? My thought was, that if callback is not set, we'll just go to power-save st= ate without extra checking, no? Something like that: const struct rte_power_monitor_cond *c =3D &pmc[i]; const uint64_t val =3D __get_umwait_val(c->addr, c->size); if (c->fn && c->fn(val, c->opaque) !=3D 0) break; Same thought for rte_power_monitor(). > + const uint64_t val =3D __get_umwait_val(pmc->addr, pmc->size); Same thing: s/pmc->/c->/ > + > + /* abort if callback indicates that we need to stop */ > + if (c->fn(val, c->opaque) !=3D 0) > + break; > + } > + > + /* none of the conditions were met, sleep until timeout */ > + if (i =3D=3D num) > + rte_power_pause(tsc_timestamp); > + > + /* end transaction region */ > + rte_xend(); > + > + return 0; > +} > -- > 2.25.1