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 2BBCDA00C5; Fri, 29 May 2020 08:56:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C72331DBD4; Fri, 29 May 2020 08:56:31 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 6A88F1DBD0 for ; Fri, 29 May 2020 08:56:30 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id y18so1245507iow.3 for ; Thu, 28 May 2020 23:56:30 -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=lB7c+16QozZcs4jmnQUv+4A8BpJKjIfeglM/xwpzseE=; b=aoy5cIXkbDaQcNUoUp+TL7p0gFFitlsCAlTI8fEmfBUyv+41m7Kdw1o1Pqmv75NmoN r7BGG3CRklaWv+e/eZzchzecmwAuOKDmQy4biLZMCLvOHkKcuogvoWjhyHe0ws/IXOm4 SNbL+FU/Syng8Xnol34qWHIwJTquT49GDMhukcCU5cEp4J6JJjaxHMLDJH5d3N8UV8L/ C1qjJE43i7mdwCpicVIwjSKLU6Dd85siF/8eAOkFXrOgcejdC8OeOSkMxZ+PJoUZwr0d kZb2ymxvdcMu0NeOFPXIIcsO+a6xI65f3TImoijE2ioM5aQfOmEqh421gZShuBYaAahV 4QCQ== 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=lB7c+16QozZcs4jmnQUv+4A8BpJKjIfeglM/xwpzseE=; b=eyExm4DbwaWHPRz8+Hl8HfthV469DKNe/eYQgoSxKuBBl8iKrgQovFf5e+4a5QunQ9 Qkuogied/10ZcBlI9dyq9oj3+1S0s/ZfrqwdypyjiMwSENoVv11tWVinCqowWOS4y7dA 6DVtjrYkF/gukuTmEyuCAuP4bFQvtiD4HT1mwPtFF19UYoJK6kNBis9L+s27cqtKXzci DtaxupB4nNut0/mUT+n7VjzsXDqxgjc3u7ZcTd+re0N7Ao7AhKXC+dwoHGr+6hPQnobU ELEena+JSyJLzDm5DLlzioHL5AiEmPELKKVZl7IJ+TibXvWXDiNPLTillvVt05ly8eon fnEw== X-Gm-Message-State: AOAM5301+t47msTqI5SElNfnQelG8j6+KAKI5OxJqrdsM5/pU3Y/ucja ZmexphvLvwlqCxZFpD2bOlg+oflqb/NgMuhI+sI= X-Google-Smtp-Source: ABdhPJyEdshFwqWcpB17ZQY1G4WjjpCgHfRSSdWI9g4DbJJO75EsKzsHwTeYAcc0kNTZljofm5ZY/LVeIKxn9SXNmQg= X-Received: by 2002:a5e:c64a:: with SMTP id s10mr5472160ioo.1.1590735389502; Thu, 28 May 2020 23:56:29 -0700 (PDT) MIME-Version: 1.0 References: <2772eb151ccba5cc17186e6161d8834176924753.1590598121.git.anatoly.burakov@intel.com> In-Reply-To: From: Jerin Jacob Date: Fri, 29 May 2020 12:26:13 +0530 Message-ID: To: "Ananyev, Konstantin" Cc: "Burakov, Anatoly" , "dev@dpdk.org" , "Richardson, Bruce" , "Hunt, David" , "Ma, Liang J" , "Honnappa.Nagarahalli@arm.com" 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 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. 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). 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