From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4CB89A04C7; Fri, 18 Sep 2020 07:01:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8281E1C201; Fri, 18 Sep 2020 07:01:48 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id DB2511C1FC for ; Fri, 18 Sep 2020 07:01:46 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id y13so5500979iow.4 for ; Thu, 17 Sep 2020 22:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RqRSldsOZ0Y2LCxfB3+iMdD6Y7qTvp+aqh25ze3yft0=; b=eHXwjiD92rb/HREfYnyElbpguyHj+4YKz8Mi+7OAiODOljA0+ltb66wucWSEGGHFo6 tBGZ7GfbnoltF1MocN1Jg9PqXI2vd/ZirJgzr6eYEk+LzlrIW+XED9IDxYsN+Ga0WF1c y8VLzz3u+v3jpXrEKqx0ve45CMpU8iWpIPPv0jhm3ARt9hfXt4uXh+zJmfFu2UjBLXBb y0LnB10JLxPSdFqiAVXkbTNyRObQwHUEOP2jFnpoyZ0WIw9DNNq3uqgReu+eHwQPKRmH zYxw0+Aj12+sU+9Z/C95TxadrUN8dgv6KnCRBEutc1rHgMPcY8lndj/Hct/dDXcfgtIh nPgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RqRSldsOZ0Y2LCxfB3+iMdD6Y7qTvp+aqh25ze3yft0=; b=i+DyGD1JUlHxf6UZDuYZruotKcKMTxuGWAnmuHt30+DKSfxzm1laq8J9gO6NK2YSgH cDxpU59zCWfcC92ezZKv7Ny6iqgPXVIMhnABvfmSllRUYnHijN4rLZ7haBzv1W2XiQR2 dPErGQwpr2xLNCtBLqa37If1UcMUx4rXQaNWoyIVfG3ExaAAV4Kpa1JaD2fHKjf/GRO0 o9ffktQJeCzw0ixGZhDoSSzLHbgYV5C8S97yEl0NDdCATZ1OE/Q34/TilPFmJ8gMN2Jb p5R+L591AK89ymZE2xUuiSlhmfv+1H04J9h6c4wT6oowrKg6Zy7kodCqjr8NtLd8WeiJ J/uQ== X-Gm-Message-State: AOAM532S9w/n+iVDVV2mzdIuXhDf4jdL/++U0L1QVU0aQKspbSCEkkSf BpiafMl8N7oNOGTRRXTUTvKyxt+p9LNE7J6Kt3w= X-Google-Smtp-Source: ABdhPJzuSsAZn8Bb79oOPeKvLK0DxVapRzsyNbsIEO/+avytnCRyRDCK0tGytL8JAnfG8etMTN81QXc4Hdazd/6RRjY= X-Received: by 2002:a05:6638:16c5:: with SMTP id g5mr17840602jat.112.1600405306152; Thu, 17 Sep 2020 22:01:46 -0700 (PDT) MIME-Version: 1.0 References: <1597141666-20621-1-git-send-email-liang.j.ma@intel.com> <1599214740-3927-1-git-send-email-liang.j.ma@intel.com> In-Reply-To: <1599214740-3927-1-git-send-email-liang.j.ma@intel.com> From: Jerin Jacob Date: Fri, 18 Sep 2020 10:31:29 +0530 Message-ID: To: Liang Ma , Honnappa Nagarahalli , Stephen Hemminger Cc: dpdk-dev , David Hunt , Anatoly Burakov , "Richardson, Bruce" , "Ananyev, Konstantin" , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 1/6] eal: add power management intrinsics X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On Fri, Sep 4, 2020 at 3:49 PM Liang Ma wrote: > > Add two new power management intrinsics, and provide an implementation > in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions > are implemented as raw byte opcodes because there is not yet widespread > compiler support for these instructions. > > The power management instructions provide an architecture-specific > function to either wait until a specified TSC timestamp is reached, or > optionally wait until either a TSC timestamp is reached or a memory > location is written to. The monitor function also provides an optional > comparison, to avoid sleeping when the expected write has already > happened, and no more writes are expected. > > Signed-off-by: Liang Ma > Signed-off-by: Anatoly Burakov > + > +#include "generic/rte_power_intrinsics.h" > + > +/** > + * Monitor specific address for changes. This will cause the CPU to enter an > + * architecture-defined optimized power state until either the specified > + * memory address is written to, or a certain TSC timestamp is reached. > + * > + * Additionally, an `expected` 64-bit value and 64-bit mask are provided. If > + * mask is non-zero, the current value pointed to by the `p` pointer will be > + * checked against the expected value, and if they match, the entering of > + * optimized power state may be aborted. > + * > + * This function uses UMONITOR/UMWAIT instructions. For more information about > + * their usage, please refer to Intel(R) 64 and IA-32 Architectures Software > + * Developer's Manual. [snip] > + */ > +static inline int rte_power_monitor(const volatile void *p, > + const uint64_t expected_value, const uint64_t value_mask, > + const uint32_t state, const uint64_t tsc_timestamp) IMO, We must introduce some arch feature-capability _get_ scheme to tell the consumer of this API is only supported on x86. Probably as functions[1] or macro flags scheme and have a stub for the other architectures as the API marked as generic ie rte_power_* not rte_x86_.. This will help the consumer to create workers based on the instruction features which can NOT be abstracted as a generic feature across the architectures. [1] struct rte_arch_inst_feat { uint32_t power_monitor : 1; /**< Power monitor */ ... } void rte_arch_inst_feat_get(struct rte_arch_inst_feat *feat);