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 EA6A3A04EF; Wed, 3 Jun 2020 08:32:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B6CC81C1C4; Wed, 3 Jun 2020 08:32:03 +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 DF3A81C1A7 for ; Wed, 3 Jun 2020 08:32:01 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id h4so970700iob.10 for ; Tue, 02 Jun 2020 23:32:01 -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=JoxFCQm2aUqKC0y6gJGoKDtM4400TMH+bFrT7XXFGKQ=; b=UviiAw04NA1oOTl9GjzW00BjZcc+sBym4rFnIunPD2rwCV/sC5dmxj3Y9au4aINUAZ NjPfVLJYO6x2CNGineQJWtc0wZKX5s4lxyaLzIrf9fB7MBQd7ctPthXcNx3ZjwD28gII dRUu6vz77CLNyNYbWhg45EeOGHZmLm+F9S4p9hbxYCDuEhZ3xP4FAmMV/qtauvlVFBep tpj29UGVlBHv01uaAOlW79b+1Vp9QYgnhbZXMz5WZnsEZAt9Agnqs+wC82KTBDODSlmT EpWHwq30cGBkMKm3kc1DCW72xghKEGOR2OxOn3bxUHezySkqMtlw4sIUZcxdezSgbqOA UNVA== 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=JoxFCQm2aUqKC0y6gJGoKDtM4400TMH+bFrT7XXFGKQ=; b=sHvus0c/Kq6bOUAh+nXvKF9qUEHHfXm1B65TsPDIUwZvgTJbExfB9onHKriGmYpLJE QQteasUfH+VRe3VCX8l+yuSbjhqwx2/ZGH40iKXgHIp2+tTN6IssCb/PNlrQT23lSHVa dgE901mQ8+0EDAv6Y22c7mCCxOPyHcmm5+3z2hJVnqZAATfRE1Lqpj9pzTlyHnZMV8KM fckT2Y6Vu2clCbFE5lxSiHdBicizjn2GB7jL8cJNjQIHOq36H/ocgnok1i1ynqZibOru pMZo+txbYBQUi6MWMTZfu/u9BtJ1KloMqDoJGzx8ZdWyMWX5WXgohCYnyUIt1OOmoFey iTSQ== X-Gm-Message-State: AOAM531Y36m2DtLc36areoaQNbvR0P1G2oOkp8q3bsbKFbWPyFsVBsDJ DtZs+fNtiob4dsij4r76ZA25rbkqHT+iiw5G7+4= X-Google-Smtp-Source: ABdhPJyMsp4BZkHERYmi7KM2DYFgqp7meXjg5aAwfdpTnJaVXr1kS98eAGQAp6hdBl0/xobSaioWEPqRPeLNyEQaT8c= X-Received: by 2002:a02:1c83:: with SMTP id c125mr28302984jac.112.1591165920954; Tue, 02 Jun 2020 23:32:00 -0700 (PDT) MIME-Version: 1.0 References: <2772eb151ccba5cc17186e6161d8834176924753.1590598121.git.anatoly.burakov@intel.com> In-Reply-To: From: Jerin Jacob Date: Wed, 3 Jun 2020 12:01:44 +0530 Message-ID: To: Honnappa Nagarahalli Cc: "Ananyev, Konstantin" , "Burakov, Anatoly" , "dev@dpdk.org" , "Richardson, Bruce" , "Hunt, David" , "Ma, Liang J" , nd Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC 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 Wed, Jun 3, 2020 at 11:53 AM Honnappa Nagarahalli wrote: > > > > > > > On Thu, May 28, 2020 at 9:08 PM Ananyev, Konstantin > > wrote: > > > > > > > > > > > Hi Anatoly, > > > > > > > > > >> > > > > >> 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. > > > > > > > > > > Recently ARM guys introduced new generic API for similar (as I > > > > > understand) purposes: rte_wait_until_equal_(16|32|64). > > > > > Probably would make sense to unite both APIs into something common > > > > > and HW transparent. > > > > > Konstantin > > > > > > > > Hi Konstantin, > > > > > > > > That's not really similar purpose. This is monitoring a cacheline > > > > for writes, not waiting on a specific value. > > > > > > I understand that. > > > > > > > The "expected" value is there > > > > as basically a hack to get around the race condition due to the fact > > > > that by the time you enter monitoring state, the write you're > > > > waiting for may have already happened. > > > > > > AFAIK, current rte_wait_until_equal_* does pretty much the same thing: > > > > > > LDXR memaddr, $reg // an address to monitor for if ($reg != > > > expected_value) > > > SEVL // arm monitor > > > do { > > > WFE // waits for write to that memory address > > > LDXR memaddr, $reg > > > } while ($reg != expected_value); > > > > > > Looks pretty similar to what rte_power_monitor() does, except you > > > don't have a loop for checking the new value. > > > Plus rte_power_monitor() provides extra options to the user - > > > timestamp and power save mode to enter. > > > Also I don't know what is the granularity of such events on ARM, is it > > > a cache-line or more/less. > > > > As I understand it, Granularity is per the cache-line. > > ie. Load-exclusive(LDXR) followed by WFE will wait in a low-power state until > > the cache line is written. > Architecture allows for 16B to 2048B space. Typically, implementations use cache-line granularity. > > > > > But I see UMONITOR bit different, Where _without_ other core signaling to > > wakeup from wait state, it can wake on TSC expiry. I think, that's is the main > > primitive on this feature. Right? > > > > WFE can also wake based on Timer stream events(kind of TSC in x86 > > analogy) but it has a configuration > > bit that needs to allow for this scheme in userspace(EL0) or not? > > defined by EL1(Linux kernel). > Timer stream events are not per CPU core. They are system wide streams. We may not need per core support to implement this use case. I think, currently, kernel configured to have a WFE signal on every 100us.(System-wide). do while{} loop can check if it is passing the requested timestamp after WFE. But minimum granularity will be 100us.(i.e 100us worth of ticks) > > > I am planning to spend time on this after understanding the value addition of > > the feature/usecase[1] [1] http://mails.dpdk.org/archives/dev/2020- > > May/168888.html > > > > > > > > > > > > > Might be ARM people can comment/correct me here. > > > Konstantin