From: Bruce Richardson <bruce.richardson@intel.com>
To: Selmon Yang <wolkayang@gmail.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] rte_eal_alarm_set() is affected by discontinuous jumps in the system time
Date: Wed, 3 Jun 2015 13:54:10 +0100 [thread overview]
Message-ID: <20150603125410.GA5880@bricha3-MOBL3> (raw)
In-Reply-To: <CA+bO-48xnexvauECRs=OCzJ1w6MtDThbinsPDceA+Yr4-zjT=w@mail.gmail.com>
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
next prev parent reply other threads:[~2015-06-03 12:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 6:31 Selmon Yang
2015-06-03 12:54 ` Bruce Richardson [this message]
2015-06-03 13:07 ` Jay Rolette
2015-06-04 2:09 ` Selmon Yang
2015-06-04 2:29 ` Selmon Yang
2015-06-04 9:39 ` Bruce Richardson
2015-06-05 2:48 ` Selmon Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150603125410.GA5880@bricha3-MOBL3 \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=wolkayang@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).