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 54E25A0350; Thu, 25 Jun 2020 00:51:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3664D2BE5; Thu, 25 Jun 2020 00:51:17 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id A97342B9E for ; Thu, 25 Jun 2020 00:51:15 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4CBAC5C0117; Wed, 24 Jun 2020 18:51:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 24 Jun 2020 18:51:15 -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=fm1; bh= RKuLJSVhOti/OWYNK3GARp+Sk4VB4WdUOGowj0E8GtA=; b=dcOVbMTYXg7BAJc0 1hIdoKdKf9CyuFoD5ym6QV3V881ENzWCcwPd/hsrA5t0mOpG8F6x1wZ9afllyl1D 2qQdgr3j+Lc9KqOYfihMZYaWpYuYLcj4k3Qcaq1y3YZl4gJWmzY84GlDCd1nRjiM JU5ZqcOlpvuh4bsQ8qbmi86R7LgLz8oxTB0WPkgZCVHNctCransOhdvYrw8+rL4j DgoRjXQSkBDU0O6b73shgWCmH/4+n34WKu3kwIAc0iKru3/OxnOTiKaAB+ZxUDYs QZPd8gjIM0ZHlHsGm8EsFyqags77ErYYWk+FiMQbtvNfYYFNC7oOArga+m52shO2 mp2tTA== 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=fm3; bh=RKuLJSVhOti/OWYNK3GARp+Sk4VB4WdUOGowj0E8G tA=; b=ACN3BSafDk+zsItFLGqnzqj21ZALLd2KTWMZv/y4oF6/SpshTS3TJ0ruD pccPcce/5NdpmFLC7hEu1YObpgNZc8hZnQkRqcuna9XoDiRXIzc42sTp+U/CbTiU XxFSaw4TUZ+yrNus9Xo9CFFF7YVorp4I3dTqwd6jM5H0gkVN2P5u+0WYmPjQxSmG eeQ4YFBVjnCfHue3TlD+OzAudGEuPgtxpx11IXMt90+XRD9HvD/Y080/yaTq49HU w3Q6u2pbvl16R6c9cQWJ6X+OU2TMaLri/EOiDcokHrCDEUbkuDtw+A2S6iOWqp5S fPLEPqcLI0IZ1gp8lZAjg5UvjAvww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekkedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 50F2A328005A; Wed, 24 Jun 2020 18:51:14 -0400 (EDT) From: Thomas Monjalon To: cristian.dumitrescu@intel.com, Alan Dewar , jasvinder.singh@intel.com Cc: Stephen Hemminger , dev@dpdk.org, Alan Dewar Date: Thu, 25 Jun 2020 00:51:13 +0200 Message-ID: <2584526.Ov0XTtHtjM@thomas> In-Reply-To: References: <1531925499-938-1-git-send-email-alan.dewar@att.com> <20180723095252.4a93ea91@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API 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" Is this old patch still relevant? 25/07/2018 11:02, Alan Dewar: > Hi Stephen, > > Sorry about the delay in responding to your comment. > > Maybe I'm missing something but I don't consider 64-bit counter > rollover to be a problem. > The DPDK QoS stats are just 32-bits wide and are zeroed when read. So > if we read them frequently enough the 32-bit counters won't wrap. > > This new API is just a convenient way to read the 32-bit counters into > variables that are 64-bit wide which allows Vyatta to have a common > API slightly above the DPDK. > > I'd hope that at some point in time the DPDK will move to 64-bit > counters, but there may be technical reasons why this can't happen > that I'm not aware of (support for 32-bit CPUs??) > > Regards > Alan > > On Mon, Jul 23, 2018 at 5:52 PM, Stephen Hemminger > wrote: > > On Wed, 18 Jul 2018 15:51:39 +0100 > > alangordondewar@gmail.com wrote: > > > >> From: Alan Dewar > >> > >> Add new APIs to retrieve counters in 64-bit wide fields. > >> > >> Signed-off-by: Alan Dewar > > > > Do you want to consider 64 bit counter roll over on 32 bit platform? > > The problem is that incrementing an 64 bit value is not atomic on > > 32 bit cpu. The carry operation can race with reading. > > > > The kernel has special case code to do restartable sequence for > > accessing 64 bit counter on 32 bit CPU. These functions become > > nop's on 64bit. >