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 3568641E77; Fri, 17 Mar 2023 02:58:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 112E540DF6; Fri, 17 Mar 2023 02:58:21 +0100 (CET) Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by mails.dpdk.org (Postfix) with ESMTP id 4E5A540A79 for ; Fri, 17 Mar 2023 02:58:19 +0100 (CET) Received: by mail-pj1-f53.google.com with SMTP id gp15-20020a17090adf0f00b0023d1bbd9f9eso7411482pjb.0 for ; Thu, 16 Mar 2023 18:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1679018298; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=y60qYCZ2njxE1vDC17eOP+GgnvOS73bIgwpvpQ04Z+Q=; b=eBxMrbYaPkZjnlgwEMc6dDYd5NgBKQ7LsV+8IHM167tM4uqlYmsGVHQhC0hQZBfsET jlBlnAEeKvXc7OAvZeiFedfb/Qmvqr+OQrapMQ4GZmBsGiALmqSsFcqOYb/zEBOgvBI4 MSdlVfs+gmWLID2chkP6gPCEPPpxJr6MSoxgIis2tR9xx+THBuIO1Bykf1FwPi2PMMFZ 7ZCaOoy46NRZ4X9Ygo13tUDHV5vNbwSol3iBZkU/yQpVBfUy90q0G0ZHnAUqacDKrBWa 4Bixj9r4HAQXLlKUKWEyzUcxfwvVkrECZ2vR8n6GDyJCU3Ua2CkBPP9cVK5/QwOHUauk 5Xnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679018298; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y60qYCZ2njxE1vDC17eOP+GgnvOS73bIgwpvpQ04Z+Q=; b=JU+2VS0MOXB6v3vtGOfu4YJkvS7QP/s/AJiFi2wYaYzINiJxQumEPmS/2suGxHsdXX vYlHtc5sQ0dfnnnjVviI1baqc1+CljZLkKeA6bJJsJkR/akzqyf6EdFXDifvFaEfyw0S qYnLDmnxJhogFiCQUdScrXlXaD13txWzJ2qgX2pc3J+p8MbXmttEsy2SP0Jyyp3WE3IS uh85LusSQ6SM4RlICuS/Y9MAvbjyX3yVZckpjyaIWlP9LsTqmqfcCBr3EK4Tum+r+DM8 oml784DydJLg3waeLioecS3ZBJV/QhUdZsreGdSQ9Ujoc05hfVwzpc+YvtrJyhFdQZZw m35g== X-Gm-Message-State: AO0yUKUA6UsLrLp2U0GcgbFgXW/dVH7VHKOSgijdtShm8xAFzuGYaFOp blMbHYRATy8vsAb0R28JavE2UA== X-Google-Smtp-Source: AK7set/IymbwtuiwD+L+c7mY7JPfI/m/e7IF7h6NcNPhXZ2YjAWSW2zOmz4WI4hDrnCUDy5aoDXjog== X-Received: by 2002:a17:90b:1643:b0:23f:2955:aabe with SMTP id il3-20020a17090b164300b0023f2955aabemr4509479pjb.8.1679018298385; Thu, 16 Mar 2023 18:58:18 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id g7-20020a17090a128700b00233ebab3770sm248612pja.23.2023.03.16.18.58.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Mar 2023 18:58:17 -0700 (PDT) Date: Thu, 16 Mar 2023 18:58:16 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: , Erik Gabriel Carrillo , David Marchand , , Stefan Sundkvist , Morten =?UTF-8?B?QnI=?= =?UTF-8?B?w7hydXA=?= , Tyler Retzlaff Subject: Re: [RFC v2 2/2] eal: add high-performance timer facility Message-ID: <20230316185816.3879decf@hermes.local> In-Reply-To: <20230315170342.214127-3-mattias.ronnblom@ericsson.com> References: <20230228093916.87206-1-mattias.ronnblom@ericsson.com> <20230315170342.214127-1-mattias.ronnblom@ericsson.com> <20230315170342.214127-3-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Wed, 15 Mar 2023 18:03:42 +0100 Mattias R=C3=B6nnblom wrote: > The htimer library attempts at providing a timer facility with roughly > the same functionality, but less overhead and better scalability than > DPDK timer library. >=20 > The htimer library employs per-lcore hierarchical timer wheels and a > message-based synchronization/MT-safety scheme. >=20 > RFC v2: > * Fix spelling. > * Fix signed/unsigned comparisons and discontinue the use of name-less > function parameters, both of which may result in compiler warnings. > * Undo the accidental removal of the bitset tests from the 'fast_tests'. > * Add a number of missing include files, causing build failures > (e.g., on AArch64 builds). > * Add perf test attempting to compare rte_timer, rte_htimer and rte_htw. > * Use nanoseconds (instead of TSC) as the default time unit. > * add() and manage() has flags which allows the caller to specify the > time unit (nanoseconds, TSC, or ticks) for the times provided. >=20 > Signed-off-by: Mattias R=C3=B6nnblom Initial reactions. Good: - timer API does need work - the units and API's model seems good, would have to look at real applic= ations - tests look good as well. Bad: - why do we need a new timer infrastructure. Could this not be done by extending and embracing the existing rte_timer() API's. - having fast rte_timer() would make existing app's faster. =20 PS: - ok to drop all the rte_alt_timer stuff, don't think any application dep= ends on it. my survey of github projects, only one usage (OpenDataplane). -=20