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 3DFABA04BC; Thu, 8 Oct 2020 17:13:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F3831C1B2; Thu, 8 Oct 2020 17:13:28 +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 61F421C1B1 for ; Thu, 8 Oct 2020 17:13:26 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id d20so6496762iop.10 for ; Thu, 08 Oct 2020 08:13:26 -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=feLo6zwmdCnTguqdpO+tmWEzUxnWJHqMrgR4eBGSNwQ=; b=VOUGCXQGl+/SHYeRNWUkgRfPG0opXScnHn0Gth2lhZDrFGqJg4wc4TkRMr21wCMLa+ UsgCbQNLeOx/O7QfGZftfbHH13a7Odjc2okwj16e7dHvv1yYF1VCmRbJZavIm+1rBYO+ b+IWmzAziGtawDO0QOukiTRoCI8rTO7dnbYasuw2sk9N66RjFuLyJnFLnK98pKwcAxIG 21alFsR0P5bPgwcc8cJz6fhaN+lP9Kw8JfWDnB33ghU2m/38NQjn9L8P061AqCdGSrxr DCVV32jwyyldWoRnz5jelgd3o6mbkd6Ndyrwm3cfFxQEbuIjYUln+o5H/NJwILB1HA9F GS8w== 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=feLo6zwmdCnTguqdpO+tmWEzUxnWJHqMrgR4eBGSNwQ=; b=SFDZDjxm18Z4PKgGGMlmFhWNGqCGrdUrnQ77fuudVOOHUhgmlB6VBIG2t5cDQn4Fvi tlpmjvf0exR2StIDdlx/hAN8f4nNnD86gIuMC3rYtk6VtXpb9RD+cTUAEhPGkoSY3fkE AyyPSEww9ebatNSVhvHxXDUk4t+/KiMgnNnhg6r5CJ/YQB7IJHsZDYtOhwxqvoK0VIwF dwpCltkCsYlg6I0A17rPlPwdLy/KhmZha6KFoprtYlwuI575WZciiX8Tv+slOkdlO+OD wcWWxGW5ZEFpS8060U3lv9xlEk0IFkvNuULZyhcd4pzZkd6iaIW03zFEpM9LLLJng5hw +yEQ== X-Gm-Message-State: AOAM53186UOTl+FIr7pjcFsuMS9EYc5HthOl2TPgxJFRKsKwMD3Y6RiR F75z2bKu+XVHJGvY9T8wB8tLF27NeGOva7S1tNk= X-Google-Smtp-Source: ABdhPJytp0aMIPw9xUafDXF89xB8CQc9hF+rf1xawyDNOJN02adVBKfyxDgXD+mIFKcDbwqEg/uPIinN7R0SYtaQ1+U= X-Received: by 2002:a5d:9e0c:: with SMTP id h12mr6242569ioh.163.1602170004605; Thu, 08 Oct 2020 08:13:24 -0700 (PDT) MIME-Version: 1.0 References: <1599214740-3927-1-git-send-email-liang.j.ma@intel.com> <1601647919-25312-1-git-send-email-liang.j.ma@intel.com> <1601647919-25312-2-git-send-email-liang.j.ma@intel.com> <16022545.g3EcnA0i2J@thomas> <1615f7c8-d0bf-bdac-141e-422497a593e2@intel.com> In-Reply-To: <1615f7c8-d0bf-bdac-141e-422497a593e2@intel.com> From: Jerin Jacob Date: Thu, 8 Oct 2020 20:43:08 +0530 Message-ID: To: "Burakov, Anatoly" Cc: Thomas Monjalon , Liang Ma , dpdk-dev , David Hunt , Stephen Hemminger , "Ananyev, Konstantin" , Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , David Christensen , Jerin Jacob Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 02/10] 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, Oct 8, 2020 at 6:57 PM Burakov, Anatoly wrote: > > On 08-Oct-20 9:44 AM, Jerin Jacob wrote: > > On Thu, Oct 8, 2020 at 2:04 PM Thomas Monjalon 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. > >>> > >>> For more details, Please reference Intel SDM Volume 2. > >> > >> I really would like to see feedbacks from other arch maintainers. > >> Unfortunately they were not Cc'ed. > > > > Shared the feedback from the arm64 perspective here. Yet to get a reply on this. > > http://mails.dpdk.org/archives/dev/2020-September/181646.html > > > >> Also please mark the new functions as experimental. > >> > >> > > Hi Jerin, Hi Anatoly, > > > 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. > > I'm not entirely sure what you mean by that. > > I mean, yes, we should have added stubs for other architectures, and we > will add those in future revisions, but what does your proposed runtime > check accomplish that cannot currently be done with CPUID flags? RTE_CPUFLAG_WAITPKG flag definition is not available in other architectures. i.e RTE_CPUFLAG_WAITPKG defined in lib/librte_eal/x86/include/rte_cpuflags.h and it is used in http://patches.dpdk.org/patch/79540/ as generic API. I doubt http://patches.dpdk.org/patch/79540/ would compile on non-x86. > > If you look at patch 1 [1], we added CPUID flags that the user can > check, and in fact this is precisely what we do in patch 4 [2] before > enabling the UMWAIT path. We could perhaps document this better and > outline the dependency on the WAITPKG CPUID flag more explicitly, but > otherwise i don't see how what you're proposing isn't already possible > to do. > > [1] http://patches.dpdk.org/patch/79539/ > [2] http://patches.dpdk.org/patch/79540/ , function > rte_power_pmd_mgmt_queue_enable() > > -- > Thanks, > Anatoly