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 8D6ABA04BC; Fri, 9 Oct 2020 11:29:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5B3711C236; Fri, 9 Oct 2020 11:29:37 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 7A4D61C235 for ; Fri, 9 Oct 2020 11:29:34 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id F0EEE58026D; Fri, 9 Oct 2020 05:29:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 09 Oct 2020 05:29:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= kajB7zzUBeR50/pM+jbpgkZIwM0KX45jwh5Wz+bvbtY=; b=do9o4iTg38dWsAqf JMjv0tAgm9Dct2V46z+NncIWLW5O68Vop5OkdLbgL0sejqwGnRqEw7SmScsVzhdr 9K6RNJ61G1ogV1Y0z+Ej5pU0AxsJ+l9ag2IxlhbvqvPZ4NBkVI5UoTmJNZyrAlFo AHbo4Y9DAUFzRKvTzSxY6CAMn+Yys8bD8KsIjUoxo+tt6pDhOh7iQmgH9TA5vBXC 0QLwptf7kzvIxWHSpmFQfGVzrUN+POu6jpgHJCHNmdpZoM+LwIvS4LhPUmbWODKe O9tBjOW3/QMPD+3jmSGwwvo+2bM9KSYDwjI3Y6RvQqOuG+uAfeCug8ne9Zw074/T Dv+E4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=kajB7zzUBeR50/pM+jbpgkZIwM0KX45jwh5Wz+bvb tY=; b=dCm5dVFBxtm1qbZB4nXkd+CCnfjNM/ukCXuKBibAtQoaO3ZsXYky2Kg6P JHQG0nvnLBcd/DJgA9EK9Al38oT/ycVaZJNk/oqmJ63MAGKP8vV6339C8cP4lFyC OcxmAs4MX6ruJ/E7UGZeKWJhmtmP6B1JrekLNoTsbbZ6wU6LAZoAtNCDuTOCryN8 fZrxRelZgkigwuJodJWb4cTkxD+rO5I4Vj65pjLff3dkUfD3RD11uVifnmy2WicW QqRf+AAHQW0BAEx+Kr8UVHuLcJevQ3g+O0elTcccxjMXkSkykGnTzvKLYcjg7uz1 /9ZuMrG3UZXbEbZDh2BAWJbLnT48A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrhedugddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeffvdffjeeuteelfeeileduudeugfetjeelveefkeejfeeigeehteff vdekfeegudenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefgedrvd dtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B109E3280064; Fri, 9 Oct 2020 05:29:30 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: Jerin Jacob , "Ananyev, Konstantin" , David Marchand , "Ma, Liang J" , dpdk-dev , "Hunt, David" , Stephen Hemminger , Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , David Christensen , Jerin Jacob Date: Fri, 09 Oct 2020 11:29:29 +0200 Message-ID: <3735900.a7ZSN3H2iV@thomas> In-Reply-To: References: <1599214740-3927-1-git-send-email-liang.j.ma@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 09/10/2020 11:25, Burakov, Anatoly: > On 09-Oct-20 6:42 AM, Jerin Jacob wrote: > > On Thu, Oct 8, 2020 at 10:38 PM Ananyev, Konstantin > > wrote: > >> > >>> > >>> 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. > >> > >> > >> I am agree with Jerin, that we need some generic way to > >> figure-out does platform supports power_monitor() or not. > >> Though not sure do we need to create a new feature-get framework here... > > > > That's works too. Some means of generic probing is fine. Following > > schemed needs > > more documentation on that usage, as, it is not straight forward compare to > > feature-get framework. Also, on the other thread, we are adding the > > new instructions like > > demote cacheline etc, maybe if the user wants to KNOW if the arch > > supports it then > > the feature-get framework is good. > > If we think, there is no other usecase for generic arch feature-get > > framework then > > we can keep the below scheme else generic arch feature is better for > > more forward > > looking use cases. > > > >> Might be just something like: > >> rte_power_monitor(...) == -ENOTSUP > >> be enough indication for that? > >> So user can just do: > >> if (rte_power_monitor(NULL, 0, 0, 0, 0) == -ENOTSUP) { > >> /* not supported path */ > >> } > >> > >> To check is that feature supported or not. > > > > > > Looking at CLDEMOTE patches, CLDEMOTE is a noop on other archs. I think > we can safely make this intrinsic as a noop on other archs as well, as > it's functionally identical to waking up immediately. > > If we're not creating this for CLDEMOTE, we don't need it here as well. > If we do need it for this, then we arguably need it for CLDEMOTE too. Sorry I don't understand what you mean, too many "it" and "this" :)