From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id E5ACABDC2 for ; Wed, 3 Jun 2015 15:07:29 +0200 (CEST) Received: by wgv5 with SMTP id 5so8732140wgv.1 for ; Wed, 03 Jun 2015 06:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jsjxuddWm9zO4tGa7iXoaH+o2i8/PBi5jCr64jfdEDU=; b=CZXO2qRMPh9nukO+0y6wvI6cq+bcdJyaccN0H3na/hELlVO9b2gSFznSPGaWxfjMWX /pbYDe69lojM+Mucs19KekBzcKE/XKItpfha6Wbk2ff3KabgXwzlWqmxcQZL3W0uqCJ3 Ju/6Q03x8ORy/YSy7rL7kcynpBwietXOLvH1fKpOy8ZdCSuzGqJJ2/ctT8Ad79OcPJem kCxTxbJc/a9/KrqMitHBks9OlZe6/AeiJp7o0+LlhDGCwmR+pHpiXaS76RLK1sl8y1EP jZtU9Hn04S2MJDM8jVYsr82D+0gNDlxZjGgqt8neo389s5S6/pvizNvMgeyEMmuOrnUZ es6Q== X-Gm-Message-State: ALoCoQkh1u+RBWbE5BgF+OTojJBYSYsHiGoJXRm8zWvDmHyEMXSwclCuTRA0420vN7gg50V2l+wj MIME-Version: 1.0 X-Received: by 10.194.58.70 with SMTP id o6mr7427137wjq.54.1433336849752; Wed, 03 Jun 2015 06:07:29 -0700 (PDT) Received: by 10.194.36.193 with HTTP; Wed, 3 Jun 2015 06:07:29 -0700 (PDT) In-Reply-To: <20150603125410.GA5880@bricha3-MOBL3> References: <20150603125410.GA5880@bricha3-MOBL3> Date: Wed, 3 Jun 2015 08:07:29 -0500 Message-ID: From: Jay Rolette To: Bruce Richardson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: DPDK Subject: Re: [dpdk-dev] rte_eal_alarm_set() is affected by discontinuous jumps in the system time 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: Wed, 03 Jun 2015 13:07:30 -0000 On Wed, Jun 3, 2015 at 7:54 AM, Bruce Richardson wrote: > On Wed, Jun 03, 2015 at 02:31:47PM +0800, Selmon Yang wrote: > > Hi, > > > > I found that, in dpdk 2.0, rte_eal_alarm_set() is affected by > > discontinuous jumps in the system time because eal_alarm_callback() > > and rte_eal_alarm_set() use gettimeofday() to get the current time. > > > > Here is what I encountered. > > I set up a rte eal alarm as below, and I like it to be triggered every > second. > > #define USE_PER_S 1000 * 1000 > > void my_alarm_cb(void *arg) > > { > > /* send heartbeat signal out, etc. */ > > > > rte_eal_alarm_set(1 * US_PER_S, my_alarm_cb, NULL); > > return; > > } > > > > int main(void) > > { > > /* ..., do something */ > > rte_eal_alarm_set(1 * US_PER_S, my_alarm_cb, NULL); > > /* ... do something else */ > > } > > > > It works fine in most of time. > > However, if I change system time manually, it is possible that rte alarm > > function works out of my expectation. > > Suppose that current time is 11:00:00 AM, and eal_alarm_callback() > > is triggered because I executed > > rte_eal_alarm_set(1 * US_PER_S, my_alarm_cb, NULL) at 10:59:59 AM. > > eal_alarm_callback() gets the current time (11:00:00 AM) > > and calls my_alarm_cb() as below. > > while ((ap = LIST_FIRST(&alarm_list)) !=NULL && > > gettimeofday(&now, NULL) == 0 && > > (ap->time.tv_sec < now.tv_sec || > > (ap->time.tv_sec == now.tv_sec && > > ap->time.tv_usec <= > > now.tv_usec))){ > > ap->executing = 1; > > ap->executing_id = pthread_self(); > > rte_spinlock_unlock(&alarm_list_lk); > > > > ap->cb_fn(ap->cb_arg); > > > > rte_spinlock_lock(&alarm_list_lk); > > > > LIST_REMOVE(ap, next); > > rte_free(ap); > > } > > > > In my_alarm_cb(), rte_eal_alarm_set() is called again. > > rte_eall_alarm_set() gets the current time (11:00:00 AM), plus 1 second, > > and adds the new alarm entry to alarm_list. > > /* use current time to calculate absolute time of alarm */ > > gettimeofday(&now, NULL); > > > > new_alarm->cb_fn = cb_fn; > > new_alarm->cb_arg = cb_arg; > > new_alarm->time.tv_usec = (now.tv_usec + us) % US_PER_S; > > new_alarm->time.tv_sec = now.tv_sec + ((now.tv_usec + us) / > US_PER_S); > > > > rte_spinlock_lock(&alarm_list_lk); > > if (!handler_registered) { > > ret |= rte_intr_callback_register(&intr_handle, > > eal_alarm_callback, NULL); > > handler_registered = (ret == 0) ? 1 : 0; > > } > > > > if (LIST_EMPTY(&alarm_list)) > > LIST_INSERT_HEAD(&alarm_list, new_alarm, next); > > else { > > LIST_FOREACH(ap, &alarm_list, next) { > > if (ap->time.tv_sec > new_alarm->time.tv_sec || > > (ap->time.tv_sec == > > new_alarm->time.tv_sec && > > > > ap->time.tv_usec > new_alarm->time.tv_usec)){ > > LIST_INSERT_BEFORE(ap, new_alarm, next); > > break; > > } > > if (LIST_NEXT(ap, next) == NULL) { > > LIST_INSERT_AFTER(ap, new_alarm, next); > > break; > > } > > } > > } > > > > After the new alarm entry is added to alarm_list, if current time is > > set to 8:00:00 AM manually, the current time in eal_alarm_callback() > > will be updated to 8:00:00 AM, too. > > Then the new alarm entry will be triggered after 3 hours and 1 second. > > > > I think rte alarm should not be affected by discontinuous jumps in > > the system time. > > I tried to replace gettimeofday() with > clock_gettime(CLOCK_MONOTONIC_RAW, &now), > > and it looks work fine. > > What do you think about this modification? > > Will you consider to modify rte_alarm functions to be not affected > > by discontinuous jumps in the system time? > > I agree with you that the alarm functionality should not be affected by > jumps > in system time. If you have a patch that fixes this bug, it would be great > if > you could upstream it here. > > Thanks, > /Bruce > I haven't looked through the RTE alarm code, but one thing to consider is whether you want to use CLOCK_MONOTONIC_RAW or just CLOCK_MONOTONIC. The RAW version is ~10x slower than the CLOCK_MONOTONIC. CLOCK_MONOTONIC isn't completely protected from NTP frequency adjustments, but it won't have discontinuities. We've found the rte_eal_alarm calls to be surprisingly (ie., we hadn't bothered to look at the implementation yet) variable and intermittently slow, so the 10x difference on the call to clock_gettime() may be relevant. Jay