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 CA84541E1C; Thu, 9 Mar 2023 16:21:03 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B7B1B410EE; Thu, 9 Mar 2023 16:21:03 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 3B0C340ED7 for ; Thu, 9 Mar 2023 16:21:02 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C695C56B7 for ; Thu, 9 Mar 2023 16:21:01 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 9D0B55B05; Thu, 9 Mar 2023 16:21:01 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -1.4 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7F3A257AA; Thu, 9 Mar 2023 16:21:00 +0100 (CET) Message-ID: <072a67ab-6627-bda2-a50f-bda5bda93aac@lysator.liu.se> Date: Thu, 9 Mar 2023 16:20:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [RFC 2/2] eal: add high-performance timer facility Content-Language: en-US To: Stephen Hemminger , =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Cc: dev@dpdk.org, Erik Gabriel Carrillo , David Marchand , maria.lingemark@ericsson.com, Stefan Sundkvist References: <20230228093916.87206-1-mattias.ronnblom@ericsson.com> <20230228093916.87206-3-mattias.ronnblom@ericsson.com> <20230305092508.6922b4b4@hermes.local> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <20230305092508.6922b4b4@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2023-03-05 18:25, Stephen Hemminger wrote: > On Tue, 28 Feb 2023 10:39:16 +0100 > Mattias Rönnblom 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. >> >> The htimer library employs per-lcore hierachical timer wheels and a >> message-based synchronization/MT-safety scheme. >> >> Signed-off-by: Mattias Rönnblom > > I like this but: > - need to have one timer infrastructure, having multiple will lead to confusion > and overlap in user applications. I.e can they be mixed, what happens if X and Y... > > - best to keep original API available. > My thoughts on this is that we first converge on the proper future API, and then you see how close it is to , and if a shim layer or something of that sort is feasible. > - ok to drop the rte_alt_timer since it was always experimental. > > - would be good to have API using consistent known time (nanoseconds?) rather > than TSC cycles. > I will update the RFC to use nanoseconds, at least as the default time unit. > - there could be use cases for REALTIME as well as MONOTONIC types. The current HTW implementation requires monotonic time (i.e., time can't go backwards). Realtime clocks typically aren't monotonically increasing. A naive implementation of backward time travel would be to just rescheduled all timers. Would you use one HTW instance per clock? This makes me think you want a small (!= ) time source API as well. It would, among other things, define the clock ids to use in the rte_htimer_mgr_add() calls. It would also be a good place in case you want to cache the result of rdtsc instructions (to have a more course-grained, but more efficient, clock source). Maybe rte_get_timer_cycles()/hz() (as opposed to rte_get_tsc_cycles()) is a minimalistic attempt in this direction already?