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 6B66F43196; Wed, 18 Oct 2023 09:14:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5E9C0406BC; Wed, 18 Oct 2023 09:14:07 +0200 (CEST) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by mails.dpdk.org (Postfix) with ESMTP id F08BD4025F for ; Wed, 18 Oct 2023 09:14:05 +0200 (CEST) Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-418201cb9e9so45151701cf.0 for ; Wed, 18 Oct 2023 00:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697613245; x=1698218045; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w16UKbmNExJS1I25NCFDsHLPmgJTVBiE+20jRyrRpyw=; b=PkXgXawiTNWuCXEJlOrXw34aqEICi6IuhqK1R1Vm86jSGfXcODi5sY8/vUMR2sMHAK 7kSCqZKR7tH6+bnsqHhwdQzSZiXKTnHCZFTodb4uD3wSoBirmk6MumWnX7gt+TUwVEJV YfHUBdk+ZB6iLTgVMrB6Nvl7+JXwQexzEVp3DrUPC01J/fcB571YLpSNH6mYbQhBeEsK SxTUY7IvzXEkCNeWLK2Kqo0KcXg7uELYCgmBEKzixk1WqeUk+UxyBxPhQyBkav471s5O MXNEV0tCAD5syKxjFmK2U8CUtEBRHtKmLF+bR7sLWOHwhBELYxSRQM2P0tOg0IvcRnKF Ig7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697613245; x=1698218045; 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=w16UKbmNExJS1I25NCFDsHLPmgJTVBiE+20jRyrRpyw=; b=gRUh3Wc4YnW1/TkAM8tG9tB9Js0JpSmx/PLd+/n2kWaS+XhsGFVoPtsPMJ2kTKYlko 9Kh95fwaOokTJ+AABB7L2/F33xOjBxS0tJ15Bh5W4cEJwHSTIarm02Yfc9CLHUUVarqs fQzZFkm90QNsyTd3kwqKFjSiTYNe70kTLq3aT5hvWJuROerfkCpBJNck+5S2z5hB/cTN w8dadQzC7YgQpze+bTfDxgODyZw8pluUZ7YKeJUM6y8xfvGG8mbn1salrvN8bpNV3RgV kynr9+ylDFYMRsbyHGHNaKi8LOgW9F9E8bQeM7MdxCI07gZBR9/krUO0hfbgQdoBxJeu v1PQ== X-Gm-Message-State: AOJu0Yxa5/GOoiLpuOdDkzzFI2pR9Cuhb/RX63gSvZL/fYb5cyf9vl+m QYDaAz/fGrrnmMk5UGCS/NYszBh3I/GbieJ4N0Y= X-Google-Smtp-Source: AGHT+IF6xWgZKPpFSm6kAiCjdWIXL7S9B6bDPImllB6+m7Bgfs5tYBE9TF9HUvSQhYlfNu2dHCzN1sfjdCUDohmRysk= X-Received: by 2002:a05:622a:7:b0:418:2242:7823 with SMTP id x7-20020a05622a000700b0041822427823mr5609592qtw.32.1697613245250; Wed, 18 Oct 2023 00:14:05 -0700 (PDT) MIME-Version: 1.0 References: <20230419095427.563185-1-sivaprasad.tummala@amd.com> <20231016205715.970999-1-sivaprasad.tummala@amd.com> <20231016205715.970999-5-sivaprasad.tummala@amd.com> In-Reply-To: From: Jerin Jacob Date: Wed, 18 Oct 2023 12:43:39 +0530 Message-ID: Subject: Re: [PATCH v1 5/6] power: add eventdev support for power management To: "Tummala, Sivaprasad" Cc: "harry.van.haaren@intel.com" , "anatoly.burakov@intel.com" , "dev@dpdk.org" , "Yigit, Ferruh" , "david.hunt@intel.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Oct 18, 2023 at 12:38=E2=80=AFPM Tummala, Sivaprasad wrote: > > [AMD Official Use Only - General] > > Hi Jerin, > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Tuesday, October 17, 2023 8:53 AM > > To: Tummala, Sivaprasad > > Cc: harry.van.haaren@intel.com; anatoly.burakov@intel.com; dev@dpdk.org= ; Yigit, > > Ferruh ; david.hunt@intel.com > > Subject: Re: [PATCH v1 5/6] power: add eventdev support for power manag= ement > > > > Caution: This message originated from an External Source. Use proper ca= ution > > when opening attachments, clicking links, or responding. > > > > > > On Tue, Oct 17, 2023 at 2:27=E2=80=AFAM Sivaprasad Tummala > > wrote: > > > > > > Add eventdev support to enable power saving when no events are > > > arriving. It is based on counting the number of empty polls and, when > > > the number reaches a certain threshold, entering an > > > architecture-defined optimized power state that will either wait unti= l > > > a TSC timestamp expires, or when events arrive. > > > > > > This API mandates a core-to-single-port mapping (i.e. one core pollin= g > > > multiple ports of event device is not supported). This should be ok a= s > > > the general use case will have one CPU core using one port to > > > enqueue/dequeue events from an eventdev. > > > > > > This design is using Eventdev PMD Dequeue callbacks. > > > > > > 1. MWAITX/MONITORX: > > > > > > When a certain threshold of empty polls is reached, the core will = go > > > into a power optimized sleep while waiting on an address of next R= X > > > descriptor to be written to. > > > > > > 2. Pause instruction > > > > > > This method uses the pause instruction to avoid busy polling. > > > > > > Signed-off-by: Sivaprasad Tummala > > > > > > Hi Siva, > > > > It does not look it is aligned with previous discussion. > > > > I spend a couple of minutes to draft semantics. Please treat as referen= ce. > > > > # IMO, only following public SLOW PATH eventdev API required.(Just shar= e the > > concept) > > > > enum rte_event_pmgmt_modes { > > /** Default power management scheme */ > > RTE_EVENT_POWER_MGMT_TYPE_DEFAULT; > > /** Use power-optimized monitoring to wait for incoming traffic */ > > RTE_EVENT_POWER_MGMT_TYPE_F_CPU_MONITOR =3D RTE_BIT(0), > > /** Use power-optimized sleep to avoid busy polling */ > > RTE_EVENT_POWER_MGMT_TYPE_F_CPU_PAUSE =3D RTE_BIT(1), > > /** HW based power management scheme found in ARM64 machines, wh= ere > > core goes to sleep state till event available on dequeue */ > > RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE =3D RTE_BIT(2), > > > > }; > > > > int rte_event_port_pmgmt_type_supported_get(uint8_t dev_id, enum > > rte_event_pmgmt_modes *mode_flags) > > /** Device must be in stop state */ > > int rte_event_port_pmgmt_enable(uint8_t dev_id, uint8_t port_id, enum > > rte_event_pmgmt_modes mode); int rte_event_port_pmgmt_disable(uint8_t > > dev_id, uint8_t port_id); > > > > # It should be self-contained, No need to add to rte_power as it is CPU= only power > > mgmt.(See RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE > > above) > > > > # Add: lib/eventdev/eventdev_pmd_pmgmt.c or so and have CPU based on po= wer > > management helper functions so that all SW PMD can be reused. > > example: > > eventdev_pmd_pmgmt_handle_monitor(uint8_t dev_id, uint8_t port_id, stru= ct > > rte_event ev[], uint16_t nb_events); > > eventdev_pmd_pmgmt_handle_pause(uint8_t dev_id, uint8_t port_id, struct > > rte_event ev[], uint16_t nb_events); > > > > > > # In rte_event_dev_start(), Fixup dev->dequeue_burst if CPU based power > > management is applicable,and it is selected. > > ie. new dev->dequeue_burst is existing PMD's dev->dequeue_burst + > > eventdev_pmd_pmgmt_handle_.. (based on power management mode selected) > > Thanks for the clarification. Will incorporate the changes in next versio= n of the patch (to support power management on event port). > With the time constraints, I will defer the power management support on e= vent port to next release. However to avoid ABI breakage, > I will split the Patchset and push the patches to support callbacks in th= is release, so we don't have to wait for next stable release to > get these changes integrated. if you follow this scheme, public callback API is not needed. # In rte_event_dev_start(), Fixup dev->dequeue_burst if CPU based power management is applicable,and it is selected. ie. new dev->dequeue_burst is existing PMD's dev->dequeue_burst + eventdev_pmd_pmgmt_handle_.. (based on power management mode selected) > > Please let me know your thoughts. > > Thanks & Regards, > Sivaprasad