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 3BCFAA0C48; Tue, 6 Jul 2021 20:50:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A591C4128B; Tue, 6 Jul 2021 20:50:42 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 2924D4120E for ; Tue, 6 Jul 2021 20:50:40 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10037"; a="206164449" X-IronPort-AV: E=Sophos;i="5.83,329,1616482800"; d="scan'208";a="206164449" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2021 11:50:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,329,1616482800"; d="scan'208";a="410328734" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga006.jf.intel.com with ESMTP; 06 Jul 2021 11:50:38 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 6 Jul 2021 11:50:38 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) 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.2242.10 via Frontend Transport; Tue, 6 Jul 2021 11:50:38 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.105) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Tue, 6 Jul 2021 11:50:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PpS40zTqOX5R8rYr1xv6M0FTIH+JUIm2iCYgkMLM+HxVLNJavuI6O/jk5sD8QRzeChppJ/K3UFqd31s+3uY5QeAzShKfV8p299U8R6YdjRo5Y9VTfhdazeDesCmG4+S8jhSjGGgEe77jPXe+8qvj/SgiQrg/6hfTeB0dj+4Cjle72btgSoRrLkfp9+sB21pl4C0c2OjGyEmld0yyOPCVWuRgZAE1wk11MvRR5IvtZHfPiWRTmzFN4EsdyNZMq/xBMtgm3tY8+5A2RB5L9reRrQvuJj+nCJdoTNK7UUFtT4ubKBbwbgYCQEX0R/AmgdqgE2mPN2UBfOYFjFRgr5Hfcw== 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=/3ClWDy4CPIvXIz2w4sm92HrUqzH24SbR71hnNch2fs=; b=E0OReC2VBmM3zgJ9XcEWxcrAskiCZkzT6LuIcE4otY6/0bIVnmai0bE/oXDTGfVU8ZC35p1NhpSwJJYgTkw0uVZo6wVzutcSM9ZIdo1kQjzWiUvQGj59ABnvj4Mw89k8eeYtEMqkIJpGJCQhScxk5DyQ+4XOIUDCXHsSO9N7mrMRLHnQWcCTG12g6aEvl+9wLNTOWu76DTKZqNDEZft11Jz5yFhQ06/0jLvpf3ZZMbaADM9WSG8Qo5M53PwlscmtZA4UyNrLccOssC6r1rLYk1Yye8OOO9sb/nX/AMZ23kJl4wtTysFmjXqFjh51/N42dcVRqEXhs8Ez+7zqWAfnQg== 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=/3ClWDy4CPIvXIz2w4sm92HrUqzH24SbR71hnNch2fs=; b=hhSrAgnxxzTR2y0UKGxiLy64PrVMWyZF2PsvGRpWnO1g8ujhWswOpIWg1PuMuBEMS5NX0paxFRveM4TcfS8RDejIYS+j6zJKM3o3IBhCILNmSPs8lj+Cg5QvQLL3qbGCvHgajhPlGCgxejGricks58NvJqg/MS4aL3A4qBMSQJ4= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM4PR11MB5392.namprd11.prod.outlook.com (2603:10b6:5:397::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.32; Tue, 6 Jul 2021 18:50:32 +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.4287.033; Tue, 6 Jul 2021 18:50:32 +0000 From: "Ananyev, Konstantin" To: "Burakov, Anatoly" , "dev@dpdk.org" , "Hunt, David" CC: "Loftus, Ciara" Thread-Topic: [PATCH v6 5/7] power: support callbacks for multiple Rx queues Thread-Index: AQHXcbGcE9tsK0WI90SZHIOtazuLp6s2R7XQ Date: Tue, 6 Jul 2021 18:50:32 +0000 Message-ID: References: <5d3a791ba126c53f1077c5f7aaa4bb55e3d90c8a.1625498488.git.anatoly.burakov@intel.com> In-Reply-To: <5d3a791ba126c53f1077c5f7aaa4bb55e3d90c8a.1625498488.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-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c90f102c-e658-475a-c0bb-08d940aeeee9 x-ms-traffictypediagnostic: DM4PR11MB5392: 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:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sbdvvaJjLrmrMAvMQWsVmlfH06cWo9sSjcbi22uRXlUw+uS1/wpvrtyMO2GC7Lmiz82jDWBKmRj3GQjGNhWT/ie1u/wewX6/pOfRbAoT8RN5scOfOjhE1U11X8zur5wDT3JGub8KiclaZsl/rszF6SS86nqWG7ieG44qNuu3AB+WCajHUbu54aEsBehE8Usa+pueNrnLuEUFddFh2/1O+ggGX6nzKbPESpMUeky6wNAEkLA4n4ARk67tofzvGIgCWXxdKlhTZn0Z2+dK4YmBaQvz4HRJ6yEZ8kAIo4vPt6ieDjUy2Bx63BUpPOkWusqOdnbxoF/34Z1zQMqYg7ARny7fhKS5nn0O1XUge68gZHEc4MT2fTOqZNGwx+ds6ESqnRjLRKmK/LhYz35/lnWvZKdxHDlumgp8q+4n2V4K7rClsd/H+tsUKFjn/1aZmOX1TiNhPvJGsDhaavS5aGQt/STLV9D1Ry05mvnt0cKHeiQe4Nt5Q+djLjICFVZ6vat+l0SrM4LKyRko+5F7J65lhKx41KfAGCSTDpytz9PSMgKyKYWqNTnjH2zNVmIiZ1wXzOubkpsJGnJEuZ6koMCeO/pBRXVbqfrC5BNqEkWAVDH7TuIJlingg42ghRehMCRXUU4e03ndcUb2zu5WnQGpWw== 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:(346002)(136003)(396003)(366004)(39860400002)(376002)(76116006)(6636002)(66556008)(38100700002)(26005)(316002)(8676002)(64756008)(5660300002)(2906002)(66476007)(66446008)(478600001)(122000001)(7696005)(6506007)(66946007)(55016002)(107886003)(52536014)(33656002)(8936002)(4326008)(110136005)(186003)(83380400001)(71200400001)(9686003)(55236004)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Pa9LLQLfErAthNeLsImStskKay0oo8GO0sfBfCRO768XysQ4oU+eF43pKa90?= =?us-ascii?Q?K/8HXYIvtRsyd768S5ZAQWF11SEndDFand9lVvDX94wK3GAjh5pQZ+V7Ulpz?= =?us-ascii?Q?aFNFd6SBQnf0sPSQVT3znqqENYEcFaIU4nyCz4AkZ1mX/pPAg9rbgk4DwOaU?= =?us-ascii?Q?bKumjFqnTE1Pc8TiXzG2ZdoMJB1hVIJMCqpiwjKaSWljdHdlxpI029DYAYNW?= =?us-ascii?Q?HJ9DxSY6KlnpFpsYwI7WKa8u6nDXcOn7Y2u8wQD44ImlKkeq573Q/K0d9qba?= =?us-ascii?Q?71WLSSjSwAzCMqsUk3h6b3/YoSavaLR2f/HKHnOUv9QgmHkb0mzGBPAFIbb4?= =?us-ascii?Q?flXZrgr6M02axid4Dcbl1Q1C2G5B7t7akxRssu+IhtbvNXF+qszTd2kjhup1?= =?us-ascii?Q?GMpaXJHGtCKXO+sor89AW1S1cvF2ntmccbHtnMQ/kBdC36CEkEZquKxjR1y6?= =?us-ascii?Q?fULHi673agKP7wQJR1lSQbrhDXqVifr+b2S0CcvW8BLFbM4XE/iuDsDss0bv?= =?us-ascii?Q?3gScZyflp0YK+8Y2MxfuBq1Cv66TvRZpKczMXT4a5TV/QC0EB2jAaBE5Hpso?= =?us-ascii?Q?bgZATVsSg1a77VXr7GBhcEMu9BKbeVcKnE7VCXh2QR73tdOct01ychl/82O1?= =?us-ascii?Q?7FI0HOwVLE4TN+ORt5+rEpTgA+//uT72ZEmpfynBHaoyOggRR33iNmUU7zwO?= =?us-ascii?Q?gqqNY6ti+sSQhEih80QqNwHh8BUdEGYxR8yKDt1EBfdCDApYwHxxQSfp/rN3?= =?us-ascii?Q?nJIaX7DRbJc6JOoO+4W4VGvvvJD1HnC3ShbSddhigQjm+IZ8P8XShJbUUK7M?= =?us-ascii?Q?5X0tlTHHYnxClM4Qw6KIKMVU5tMBhdaMSGSBTMroFDilLzQgCR4lOwnHzHlr?= =?us-ascii?Q?1e1TwkObaPEDKGNHgaCrfVj9jj0H7uSGWcQyc3mbiwwoGE5rHNPuGJE7zkMA?= =?us-ascii?Q?yeGvLdBtcksDQYam5sgTfGBI8lCMGav+8wUb/Y9/lreL02sZHOUq3TaJKsl2?= =?us-ascii?Q?LgDb182lcAHTuvn3wKLnLV/EnWNHeKzSSWq54S5hVA20Y+auexSsUrcFV1dY?= =?us-ascii?Q?R0r4UMfwhn+FgVd/OkI0B1vDU6Tm85CaPydI2LUsM3MI25RdxuGWfhw8h80H?= =?us-ascii?Q?zj5leibPf7weE0z/5yOExNy/hiYWsMqbkAGlzES6csny4rqxbNUbN5R9lX8W?= =?us-ascii?Q?RZTmcWXNqz2FNnHT127vz1VoVKTbIR/bSbjcG8+l8t7kyCiHwnQRi2ZGHd9p?= =?us-ascii?Q?2wus81GLb/zROfRbsuHu+gsn9w68J5CqSt7YLdLVgrLyW91qKodAVp0cy6LI?= =?us-ascii?Q?lWdjg99Vp2YtYcyWSTIHDWqP?= 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: c90f102c-e658-475a-c0bb-08d940aeeee9 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 18:50:32.5050 (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: vTvShE92382FjyUXOsDyNkALVzMR8fVFex1TcMW8LqKQi3R4tX7vCvA/wBbFmG7KAT9FxfLz6CIcf9EKXgLMGyX5F2ScLI/gIlO2N0y+uz4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5392 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v6 5/7] power: support callbacks for multiple Rx queues 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" > Currently, there is a hard limitation on the PMD power management > support that only allows it to support a single queue per lcore. This is > not ideal as most DPDK use cases will poll multiple queues per core. >=20 > The PMD power management mechanism relies on ethdev Rx callbacks, so it > is very difficult to implement such support because callbacks are > effectively stateless and have no visibility into what the other ethdev > devices are doing. This places limitations on what we can do within the > framework of Rx callbacks, but the basics of this implementation are as > follows: >=20 > - Replace per-queue structures with per-lcore ones, so that any device > polled from the same lcore can share data > - Any queue that is going to be polled from a specific lcore has to be > added to the list of queues to poll, so that the callback is aware of > other queues being polled by the same lcore > - Both the empty poll counter and the actual power saving mechanism is > shared between all queues polled on a particular lcore, and is only > activated when all queues in the list were polled and were determined > to have no traffic. > - The limitation on UMWAIT-based polling is not removed because UMWAIT > is incapable of monitoring more than one address. >=20 > Also, while we're at it, update and improve the docs. >=20 > Signed-off-by: Anatoly Burakov > --- >=20 > Notes: > v6: > - Track each individual queue sleep status (Konstantin) > - Fix segfault (Dave) >=20 > v5: > - Remove the "power save queue" API and replace it with mechanism sug= gested by > Konstantin >=20 > v3: > - Move the list of supported NICs to NIC feature table >=20 > v2: > - Use a TAILQ for queues instead of a static array > - Address feedback from Konstantin > - Add additional checks for stopped queues >=20 > doc/guides/nics/features.rst | 10 + > doc/guides/prog_guide/power_man.rst | 65 ++-- > doc/guides/rel_notes/release_21_08.rst | 3 + > lib/power/rte_power_pmd_mgmt.c | 452 +++++++++++++++++++------ > 4 files changed, 394 insertions(+), 136 deletions(-) >=20 > diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst > index 403c2b03a3..a96e12d155 100644 > --- a/doc/guides/nics/features.rst > +++ b/doc/guides/nics/features.rst > @@ -912,6 +912,16 @@ Supports to get Rx/Tx packet burst mode information. > * **[implements] eth_dev_ops**: ``rx_burst_mode_get``, ``tx_burst_mode_g= et``. > * **[related] API**: ``rte_eth_rx_burst_mode_get()``, ``rte_eth_tx_burst= _mode_get()``. >=20 > +.. _nic_features_get_monitor_addr: > + > +PMD power management using monitor addresses > +-------------------------------------------- > + > +Supports getting a monitoring condition to use together with Ethernet PM= D power > +management (see :doc:`../prog_guide/power_man` for more details). > + > +* **[implements] eth_dev_ops**: ``get_monitor_addr`` > + > .. _nic_features_other: >=20 > Other dev ops not represented by a Feature > diff --git a/doc/guides/prog_guide/power_man.rst b/doc/guides/prog_guide/= power_man.rst > index c70ae128ac..ec04a72108 100644 > --- a/doc/guides/prog_guide/power_man.rst > +++ b/doc/guides/prog_guide/power_man.rst > @@ -198,34 +198,41 @@ Ethernet PMD Power Management API > Abstract > ~~~~~~~~ >=20 > -Existing power management mechanisms require developers > -to change application design or change code to make use of it. > -The PMD power management API provides a convenient alternative > -by utilizing Ethernet PMD RX callbacks, > -and triggering power saving whenever empty poll count reaches a certain = number. > - > -Monitor > - This power saving scheme will put the CPU into optimized power state > - and use the ``rte_power_monitor()`` function > - to monitor the Ethernet PMD RX descriptor address, > - and wake the CPU up whenever there's new traffic. > - > -Pause > - This power saving scheme will avoid busy polling > - by either entering power-optimized sleep state > - with ``rte_power_pause()`` function, > - or, if it's not available, use ``rte_pause()``. > - > -Frequency scaling > - This power saving scheme will use ``librte_power`` library > - functionality to scale the core frequency up/down > - depending on traffic volume. > - > -.. note:: > - > - Currently, this power management API is limited to mandatory mapping > - of 1 queue to 1 core (multiple queues are supported, > - but they must be polled from different cores). > +Existing power management mechanisms require developers to change applic= ation > +design or change code to make use of it. The PMD power management API pr= ovides a > +convenient alternative by utilizing Ethernet PMD RX callbacks, and trigg= ering > +power saving whenever empty poll count reaches a certain number. > + > +* Monitor > + This power saving scheme will put the CPU into optimized power state = and > + monitor the Ethernet PMD RX descriptor address, waking the CPU up whe= never > + there's new traffic. Support for this scheme may not be available on = all > + platforms, and further limitations may apply (see below). > + > +* Pause > + This power saving scheme will avoid busy polling by either entering > + power-optimized sleep state with ``rte_power_pause()`` function, or, = if it's > + not supported by the underlying platform, use ``rte_pause()``. > + > +* Frequency scaling > + This power saving scheme will use ``librte_power`` library functional= ity to > + scale the core frequency up/down depending on traffic volume. > + > +The "monitor" mode is only supported in the following configurations and= scenarios: > + > +* If ``rte_cpu_get_intrinsics_support()`` function indicates that > + ``rte_power_monitor()`` is supported by the platform, then monitoring = will be > + limited to a mapping of 1 core 1 queue (thus, each Rx queue will have = to be > + monitored from a different lcore). > + > +* If ``rte_cpu_get_intrinsics_support()`` function indicates that the > + ``rte_power_monitor()`` function is not supported, then monitor mode w= ill not > + be supported. > + > +* Not all Ethernet drivers support monitoring, even if the underlying > + platform may support the necessary CPU instructions. Please refer to > + :doc:`../nics/overview` for more information. > + ....=20 > +static inline void > +queue_reset(struct pmd_core_cfg *cfg, struct queue_list_entry *qcfg) > +{ > + const bool is_ready_to_sleep =3D qcfg->n_empty_polls > EMPTYPOLL_MAX; > + > + /* reset empty poll counter for this queue */ > + qcfg->n_empty_polls =3D 0; > + /* reset the queue sleep counter as well */ > + qcfg->n_sleeps =3D 0; > + /* remove the queue from list of cores ready to sleep */ > + if (is_ready_to_sleep) > + cfg->n_queues_ready_to_sleep--; > + /* > + * no need change the lcore sleep target counter because this lcore wil= l > + * reach the n_sleeps anyway, and the other cores are already counted s= o > + * there's no need to do anything else. > + */ > +} > + > +static inline bool > +queue_can_sleep(struct pmd_core_cfg *cfg, struct queue_list_entry *qcfg) > +{ > + /* this function is called - that means we have an empty poll */ > + qcfg->n_empty_polls++; > + > + /* if we haven't reached threshold for empty polls, we can't sleep */ > + if (qcfg->n_empty_polls <=3D EMPTYPOLL_MAX) > + return false; > + > + /* > + * we've reached a point where we are able to sleep, but we still need > + * to check if this queue has already been marked for sleeping. > + */ > + if (qcfg->n_sleeps =3D=3D cfg->sleep_target) > + return true; > + > + /* mark this queue as ready for sleep */ > + qcfg->n_sleeps =3D cfg->sleep_target; > + cfg->n_queues_ready_to_sleep++; So, assuming there is no incoming traffic, should it be: 1) poll_all_queues(times=3DEMPTYPOLL_MAX); sleep; poll_all_queues(times=3D1= ); sleep; poll_all_queues(times=3D1); sleep; ... OR 2) poll_all_queues(times=3DEMPTYPOLL_MAX); sleep; poll_all_queues(times=3D = EMPTYPOLL_MAX); sleep; poll_all_queues(times=3D EMPTYPOLL_MAX); sleep; ... ? My initial thought was 2) but might be the intention is 1)? > + > + return true; > +} > + > +static inline bool > +lcore_can_sleep(struct pmd_core_cfg *cfg) > +{ > + /* are all queues ready to sleep? */ > + if (cfg->n_queues_ready_to_sleep !=3D cfg->n_queues) > + return false; > + > + /* we've reached an iteration where we can sleep, reset sleep counter *= / > + cfg->n_queues_ready_to_sleep =3D 0; > + cfg->sleep_target++; > + > + return true; > +} > + > static uint16_t > clb_umwait(uint16_t port_id, uint16_t qidx, struct rte_mbuf **pkts __rte= _unused, > - uint16_t nb_rx, uint16_t max_pkts __rte_unused, > - void *addr __rte_unused) > + uint16_t nb_rx, uint16_t max_pkts __rte_unused, void *arg) > { > + struct queue_list_entry *queue_conf =3D arg; >=20 > - struct pmd_queue_cfg *q_conf; > - > - q_conf =3D &port_cfg[port_id][qidx]; > - > + /* this callback can't do more than one queue, omit multiqueue logic */ > if (unlikely(nb_rx =3D=3D 0)) { > - q_conf->empty_poll_stats++; > - if (unlikely(q_conf->empty_poll_stats > EMPTYPOLL_MAX)) { > + queue_conf->n_empty_polls++; > + if (unlikely(queue_conf->n_empty_polls > EMPTYPOLL_MAX)) { > struct rte_power_monitor_cond pmc; > - uint16_t ret; > + int ret; >=20 > /* use monitoring condition to sleep */ > ret =3D rte_eth_get_monitor_addr(port_id, qidx, > @@ -97,60 +231,77 @@ clb_umwait(uint16_t port_id, uint16_t qidx, struct r= te_mbuf **pkts __rte_unused, > rte_power_monitor(&pmc, UINT64_MAX); > } > } else > - q_conf->empty_poll_stats =3D 0; > + queue_conf->n_empty_polls =3D 0; >=20 > return nb_rx; > } >=20