From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id CCA4C43186;
	Tue, 17 Oct 2023 05:23:25 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 8B25B402B3;
	Tue, 17 Oct 2023 05:23:25 +0200 (CEST)
Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com
 [209.85.160.179])
 by mails.dpdk.org (Postfix) with ESMTP id 95BE04021D
 for <dev@dpdk.org>; Tue, 17 Oct 2023 05:23:24 +0200 (CEST)
Received: by mail-qt1-f179.google.com with SMTP id
 d75a77b69052e-419cc494824so36427061cf.2
 for <dev@dpdk.org>; Mon, 16 Oct 2023 20:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697513004; x=1698117804; 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=S5XeiqRUtOgriMd+Q+YU0sfuLrdPELTcILX55FzAmlw=;
 b=KUniDO6k5xUWpEufB2eq/7oV+CrUJJV1F1Ol38wKNnO1mSL3vMxD0nJYH8dfFf1/Ah
 UzfoSo+tmQvI07oayv2ebHnjLEP69KQxKCTRawe3tfrga7lSM5MNKe9HlDSfdGvW8DaE
 yhShEuv4gihAVmeC+JtPpWOD24t8KfstVsKIY0OxEGb2REgE9TWoiOVYq03WgXNlC41c
 W53nYSjEbfCAxO12y/ZBW8Tnb9JsngC8PoOZ1ZF8IlrpHs6eqPqNnVpKwoF6H1+STHjk
 zqJ0RZCkkUeXxN2Ht2DuaLVrSYksAeOL77qI2pQqYUaztybRJuwk1War160PHWNQl8/y
 Xhvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697513004; x=1698117804;
 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=S5XeiqRUtOgriMd+Q+YU0sfuLrdPELTcILX55FzAmlw=;
 b=Ni6OIEpQeH23jfuU+Ep/g33m+1ck5xNMK8Vbdr4FcMX3ghmN33LYKSFdjW6YmderD2
 PatthyVnppd8/TP4xnEx29llqaiyJThipakXm4EmTquJveJyWyRv3raG05kUV6iUBhdB
 7lD6W2O4eZhG/za/thZbLfin/lJROUPjer8UtoQaIze4091SH13OBCp9taBaKfk1Q4xB
 7oR357u6t96ZKG2l3H49X2dBklDRcEzD/MYYlRkMKD1s2fsbeZDV1nmaX6CDDmpu3Q9n
 z/jsH87aEPRcKRwFIHHJeWLSURX8X4HgHF2NMkKhfWlpqqDUkdrMwGX4rauzD90I1Z1E
 JWvA==
X-Gm-Message-State: AOJu0YxM9+NgX0wZ1QKVdoPmaXzhWszKzAPwb9irecVHyIqPoMG+x20v
 ouImLBlik/QpNM4OTPlcdFwCN5BtZsDK2GurcRI=
X-Google-Smtp-Source: AGHT+IHQSltknegHtdrFnITMifuFEhq+Ikn4DeFnfDBMkQeL9wvlUL3XuUMIiWnPlGux63TMUbqiZFO26di1SVfEe48=
X-Received: by 2002:ac8:7d4a:0:b0:418:21ad:fafe with SMTP id
 h10-20020ac87d4a000000b0041821adfafemr1608772qtb.28.1697513003813; Mon, 16
 Oct 2023 20:23:23 -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: <20231016205715.970999-5-sivaprasad.tummala@amd.com>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Tue, 17 Oct 2023 08:52:57 +0530
Message-ID: <CALBAE1Oot07_d0DqmZ=Kkxm+VP6koZWHN0tE_AdK3+SX4diZTA@mail.gmail.com>
Subject: Re: [PATCH v1 5/6] power: add eventdev support for power management
To: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
Cc: harry.van.haaren@intel.com, anatoly.burakov@intel.com, dev@dpdk.org, 
 ferruh.yigit@amd.com, 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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Tue, Oct 17, 2023 at 2:27=E2=80=AFAM Sivaprasad Tummala
<sivaprasad.tummala@amd.com> 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
> until a TSC timestamp expires, or when events arrive.
>
> This API mandates a core-to-single-port mapping (i.e. one core polling
> multiple ports of event device is not supported). This should be ok
> as 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 RX
>    descriptor to be written to.
>
> 2. Pause instruction
>
>    This method uses the pause instruction to avoid busy polling.
>
> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>


Hi Siva,

It does not look it is aligned with previous discussion.

I spend a couple of minutes to draft semantics. Please treat as reference.

# IMO, only following public SLOW PATH eventdev API required.(Just
share 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,
where 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
power 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,
struct 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)