> > Bug: When a timer is running
> >
> > - if rte_timer_stop is called, the pending decrement is
> > skipped (decremented only if the timer is pending) and due
> > to the update flag the future processing is skipped so the
> > timer is counted as pending while it is stopped. - the same
> >
2014-05-23 16:52, Olivier MATZ:
> > Bug: when a periodic timer's callback is running, if another
> > timer is manipulated, the periodic timer is not reloaded.
> > Solution: set the update flag only is the modified timer is
> > in RUNNING state
>
> Acked-by: Olivier Matz
Applied in version 1.7.
Hi Vadim,
It's even more simple that what I've suggested. It should
work since the only case where state is RTE_TIMER_RUNNING
is that we are modifying the timer currently running on the
same lcore. Indeed, timer_set_config_state() prevents us to
modify a running timer belonging to another lcore.
Acked-by: Olivier Matz
On 05/21/2014 10:35 PM, Vadim Suraev wrote:
> Bug: When a timer is running
> - if rte_timer_stop is called, the pending decrement is
> skipped (decremented only if the timer is pending) and due
> to the update flag the future processing is skipped so the
> timer is
Bug: When a timer is running
- if rte_timer_stop is called, the pending decrement is
skipped (decremented only if the timer is pending) and due
to the update flag the future processing is skipped so the
timer is counted as pending while it is stopped. - the same
applies when rte_timer_reset is
Bug: when a periodic timer's callback is running, if another
timer is manipulated, the periodic timer is not reloaded.
Solution: set the update flag only is the modified timer is
in RUNNING state
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |8 ++--
1 file changed, 6 i
6 matches
Mail list logo
