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 B9EAAA04BC; Thu, 8 Oct 2020 15:27:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0A3C41BFFC; Thu, 8 Oct 2020 15:27:02 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id BBF6A1BFF9 for ; Thu, 8 Oct 2020 15:26:59 +0200 (CEST) IronPort-SDR: VInsJ6p7aASiIB8JiSbgU9zh22Miyh3lfeJZGHAtzBJ0F7GojgK8IM544e/dM3/jjP2zfhf2x6 Ef0LRetCDf+A== X-IronPort-AV: E=McAfee;i="6000,8403,9767"; a="165442665" X-IronPort-AV: E=Sophos;i="5.77,350,1596524400"; d="scan'208";a="165442665" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 06:26:58 -0700 IronPort-SDR: BMSbcBpHPClEmklQzfnZcnr0BhOEzFHVv5U0rPh0MFqveRBh66yQUJ9W1z22s/QGu32czZmZr3 Q7WqtZWDRQDg== X-IronPort-AV: E=Sophos;i="5.77,350,1596524400"; d="scan'208";a="528493294" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.226.43]) ([10.213.226.43]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2020 06:26:53 -0700 To: Jerin Jacob , Thomas Monjalon Cc: Liang Ma , dpdk-dev , David Hunt , Stephen Hemminger , "Ananyev, Konstantin" , Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , David Christensen , Jerin Jacob 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> From: "Burakov, Anatoly" Message-ID: <1615f7c8-d0bf-bdac-141e-422497a593e2@intel.com> Date: Thu, 8 Oct 2020 14:26:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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, > 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? 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