From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id 875BF58EF for ; Fri, 6 Sep 2013 08:45:26 +0200 (CEST) Received: by mail-pa0-f43.google.com with SMTP id hz10so2930303pad.30 for ; Thu, 05 Sep 2013 23:46:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=yW7Ir3Kkm/SVjgUdsStmvU2U/T40Mjk/UHZGBOW8OWQ=; b=gxtnpjoQrnmP1ywEZ3K784zHTUmKcbm7i11Lgn3VQ/wFFWCaDVrBBv5PYNuLSLQcmu mZuCMrESamFP575E7qVtCKDenDfY+42axMHoGY0K5wjJm26ZPQAlfk5c9iP6oblrb8YT s56Z6OwSzXELpJurjFO2pEyMQxoKq5kwHw5cIo/9kEaUa8q+vFs1tW12BIz+F4oKGJbN k/5cFqEHQB3/ZlypHL1NB0D9L0Ev8Sa9QnHgkbC9US5rnOsvZKzA4RBeheKX7IZxKBrT wsIGMjxxkmKCMrbGdxpDFo5NqmDmkp1QtABimmP0mAHvUz3U0ZkRv0cJu6Tnxl6vAeOa wl9A== X-Gm-Message-State: ALoCoQnrdEQwMTQlWze2Vfrk8O3BrwTojcboICDoNQZVLNEs8Nl/5gHcM8agcAIEsp4C2yOd7xYO X-Received: by 10.68.254.226 with SMTP id al2mr1011643pbd.157.1378449961045; Thu, 05 Sep 2013 23:46:01 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-69-237.bvtn.or.frontiernet.net. [50.53.69.237]) by mx.google.com with ESMTPSA id q1sm1616360pbd.12.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 05 Sep 2013 23:46:00 -0700 (PDT) Date: Thu, 5 Sep 2013 23:45:58 -0700 From: Stephen Hemminger To: Dmitry Vyal Message-ID: <20130905234558.71593fb4@nehalam.linuxnetplumber.net> In-Reply-To: <52297756.7060308@gmail.com> References: <16BB02EF-879C-4DB1-804E-E5E6E08B935E@mahan.org> <52297756.7060308@gmail.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Recommended method of getting timestamps? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 06:45:27 -0000 On Fri, 06 Sep 2013 10:33:58 +0400 Dmitry Vyal wrote: > Hello Patrick, > > I guess gettimeofday is too heavy if all you need is an abstract > timestamp not related to any particular calendar. I think you should > look at rte_rdtsc()? It returns a current value of CPU tick counter. So > it's very cheap (just a few clocks) and has a great resolution (a > fraction of nanosecond). > > Regards, > Dmitry > > > I have a need to keep a timestamp on a piece of global data. When then timestamp grows too old I want to refresh that data. Is it safe to use, gettimeofday()? > > > > I thought about using an alarm, but I need to set an alarm from inside the alarm callback which doesn't look like it will work due to the spinlock on the alarm list. > > > > And since this is inside the driver I am working on, setting up a timer is not simple. > > > > So, I figure to timestamp the data, wait until I need to access it, check the timestamp and refresh if it is too old. > > > > Thoughts? Suggestions? > > > > Thanks, > > > > Patrick > > > > Coming to you from deep inside Fortress Mahan > DPDK has both HPET and TSC timers. HPET is slower to access non-cached, but has advantage of being same on all cores and unaffected by power management etc. TSC is faster but can vary in frequency on some processors. It is also not guaranteed sync'd on some systems with multiple sockets. See rte_rdtsc and rte_get_hpet_cycles. The latest DPDK 1.4.1 just released by Intel has common code rte_get_timer_cycles() to try and make decision at runtime.