[dpdk-dev] rte_eal_alarm_set() is affected by discontinuous jumps in the system time

Jay Rolette rolette at infiniteio.com
Wed Jun 3 15:07:29 CEST 2015


On Wed, Jun 3, 2015 at 7:54 AM, Bruce Richardson <bruce.richardson at intel.com
> 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


More information about the dev mailing list