From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 44890A0524; Thu, 6 May 2021 10:08:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6909B410DB; Thu, 6 May 2021 10:08:47 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 8885C40040 for ; Thu, 6 May 2021 10:08:46 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A4AEB5C00BA; Thu, 6 May 2021 04:08:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 06 May 2021 04:08:43 -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= mXMT44DiTXgFGPvBtq9N4CDTOOUenEDL09POqo0CWwg=; b=rZGFXSUXxPGqg7zj SNFoKW5mc4GqnqmWiW3xiV4IEjshJveozb6aWm6PPMfiyR1PSZ5srGQCrfe8fi00 zwxJmykjQaU/SwpIKSLJrFm5srzF9b3L/Dk3F/Pd63molbbCOPVcrNXXhjsr65Am 2bgUbbfO0zKCtuvhE1WnHYoqU9qNNIZtAMS9bqzi1kiTPQIGTvprhhB2mUfMzAqu 2YAxW8Du2SRgaqouzvGsU6Cfjs9XdZxJ9REJb1WgJqNffKApeNiB42ztsIIWdUwD Tw7qG6q3U+Uc5au17nuEI3tWLCQNu1sDvnLRtNPDbWmbV/exBnG1cHbNiidrDrN3 XbYIaw== 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=fm2; bh=mXMT44DiTXgFGPvBtq9N4CDTOOUenEDL09POqo0CW wg=; b=KDrbtz6LGX1BFPKC0tl+mN9VN7jd2uYBaf1LpHbs0xW5meXmpJ+1VaY8E RML/Odd2EaQhNxBBVMQ3IOJYCOi0FVDYYY6v0ChVS/jPmjeZChYA6VycJoIQ82bw +88y8c6US85EWAn63pISLYFddn6WbViWrBi1jD24HBqJwZGjBLJVbjBNfdq42zV5 CyGtas609UlyQao70zQknY9oQ1lxSskOsr7VPNZ4xhjIhD/YbnNVWYrNcarMIzwI 6d4BRIjf/IaXmaUh32GCry8MPjmVk9HpFMP3CjuG2W3YUNgIlm1lH9SAISrQ2eHo 3RndP8dkurCY6WkSDEQufOon+Mi/g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefledguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth 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; Thu, 6 May 2021 04:08:41 -0400 (EDT) From: Thomas Monjalon To: "Min Hu (Connor)" , Chengchang Tang Cc: dev@dpdk.org, ferruh.yigit@intel.com, rsanford@akamai.com, erik.g.carrillo@intel.com Date: Thu, 06 May 2021 10:08:39 +0200 Message-ID: <2452528.adedXRvZAq@thomas> In-Reply-To: References: <1618470748-12369-1-git-send-email-humin29@huawei.com> <1986861.sBpPVbSSCl@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] examples/timer: fix incorrect time interval X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 06/05/2021 04:06, Chengchang Tang: > > On 2021/5/6 5:37, Thomas Monjalon wrote: > > 15/04/2021 09:12, Min Hu (Connor): > >> From: Chengchang Tang > >> > >> Timer sample example assumes that the frequency of the timer is about > >> 2Ghz to control the period of calling rte_timer_manage(). But this > >> assumption is easy to fail. For example. the frequency of tsc on ARM64 > >> is much less than 2Ghz. > >> > >> This patch uses the frequency of the current timer to calculate the > >> correct time interval to ensure consistent result on all platforms. > >> > >> In addition, the rte_rdtsc() is replaced with the more recommended > >> rte_get_timer_cycles function in this patch. > >> > >> Fixes: af75078fece3 ("first public release") > >> Cc: stable@dpdk.org > >> > >> Signed-off-by: Chengchang Tang > >> Signed-off-by: Min Hu (Connor) > > [...] > >> /* > >> - * Call the timer handler on each core: as we don't > >> - * need a very precise timer, so only call > >> - * rte_timer_manage() every ~10ms (at 2Ghz). In a real > >> - * application, this will enhance performances as > >> - * reading the HPET timer is not efficient. > >> + * Call the timer handler on each core: as we don't need a > >> + * very precise timer, so only call rte_timer_manage() > >> + * every ~10ms. since rte_eal_hpet_init() has not been > >> + * called, the rte_rdtsc() will be used at runtime. > > > > I don't understand this last sentence. > > > > This is explaining why we can use rte_get_timer_cycles() instead of rte_rdtsc(). > In this example, we call tsc to improve its performance. So, we invoked rte_rdtsc() > here. Now the function rte_get_timer_cycles() encapsulates these counters. It will > invoke the corresponding counter according to the user's initialization of the counter. That's very confusing. Better to drop. > > >> + * In a real application, this will enhance performances > >> + * as reading the HPET timer is not efficient. > >> */ > >> - cur_tsc = rte_rdtsc(); > >> + cur_tsc = rte_get_timer_cycles();