DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] timer bug fix
@ 2014-05-21 19:53 Vadim Suraev
  2014-05-23 14:52 ` Olivier MATZ
  0 siblings, 1 reply; 6+ messages in thread
From: Vadim Suraev @ 2014-05-21 19:53 UTC (permalink / raw)
  To: dev

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 <vadim.suraev@gmail.com>
---
 lib/librte_timer/rte_timer.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 884ee0e..1ebd223 100755
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -378,7 +378,9 @@ __rte_timer_reset(struct rte_timer *tim, uint64_t expire,
 		return -1;
 
 	__TIMER_STAT_ADD(reset, 1);
-	priv_timer[lcore_id].updated = 1;
+	if(prev_status.state == RTE_TIMER_RUNNING) {
+		priv_timer[lcore_id].updated = 1;
+	}
 
 	/* remove it from list */
 	if (prev_status.state == RTE_TIMER_PENDING) {
@@ -453,7 +455,9 @@ rte_timer_stop(struct rte_timer *tim)
 		return -1;
 
 	__TIMER_STAT_ADD(stop, 1);
-	priv_timer[lcore_id].updated = 1;
+	if(prev_status.state == RTE_TIMER_RUNNING) {
+		priv_timer[lcore_id].updated = 1;
+	}
 
 	/* remove it from list */
 	if (prev_status.state == RTE_TIMER_PENDING) {
-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] [PATCH] timer bug fix
  2014-05-21 19:53 [dpdk-dev] [PATCH] timer bug fix Vadim Suraev
@ 2014-05-23 14:52 ` Olivier MATZ
  2014-05-26 16:24   ` Thomas Monjalon
  0 siblings, 1 reply; 6+ messages in thread
From: Olivier MATZ @ 2014-05-23 14:52 UTC (permalink / raw)
  To: Vadim Suraev, dev

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.

Just 3 small typos:

On 05/21/2014 09:53 PM, Vadim Suraev wrote:
> 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

s/is the modified/if the modified

> -	priv_timer[lcore_id].updated = 1;
> +	if(prev_status.state == RTE_TIMER_RUNNING) {
> +		priv_timer[lcore_id].updated = 1;
> +	}

missing a space after the if.

> -	priv_timer[lcore_id].updated = 1;
> +	if(prev_status.state == RTE_TIMER_RUNNING) {
> +		priv_timer[lcore_id].updated = 1;
> +	}

same here.

Acked-by: Olivier Matz <olivier.matz@6wind.com>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] [PATCH] timer bug fix
  2014-05-23 14:52 ` Olivier MATZ
@ 2014-05-26 16:24   ` Thomas Monjalon
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Monjalon @ 2014-05-26 16:24 UTC (permalink / raw)
  To: Vadim Suraev; +Cc: dev

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 <olivier.matz@6wind.com>

Applied in version 1.7.0 with title:
	timer: fix reloading after changes

Thanks
-- 
Thomas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] [PATCH] timer bug fix.
  2014-05-23 14:44 ` Olivier MATZ
@ 2014-05-26 16:25   ` Thomas Monjalon
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Monjalon @ 2014-05-26 16:25 UTC (permalink / raw)
  To: Vadim Suraev; +Cc: dev

> > 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 called but then the pending
> >   statistics is additionally incremented so the timer is
> >   counted pending twice.
> > 
> > Solution: decrement the pending
> > 
> >   statistics after returning from the callback. If
> >   rte_timer_stop was called, it skipped decrementing the
> >   pending statistics. If rte_time_reset was called, the
> >   pending statistics was incremented. If neither was called
> >   and the timer is periodic, the pending statistics is
> >   incremented when it is reloaded
> > 
> > Signed-off-by: Vadim Suraev <vadim.suraev@gmail.com>
> 
> Acked-by: Olivier Matz <olivier.matz@6wind.com>

Applied for version 1.7.0 with title:
	timer: fix pending counter

Thanks
-- 
Thomas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-dev] [PATCH] timer bug fix.
  2014-05-21 20:35 Vadim Suraev
@ 2014-05-23 14:44 ` Olivier MATZ
  2014-05-26 16:25   ` Thomas Monjalon
  0 siblings, 1 reply; 6+ messages in thread
From: Olivier MATZ @ 2014-05-23 14:44 UTC (permalink / raw)
  To: Vadim Suraev, dev

Acked-by: Olivier Matz <olivier.matz@6wind.com>

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 counted as pending while it is stopped. - the same
>   applies when rte_timer_reset is called but then the pending
>   statistics is additionally incremented so the timer is
>   counted pending twice.
> Solution: decrement the pending
>   statistics after returning from the callback. If
>   rte_timer_stop was called, it skipped decrementing the
>   pending statistics. If rte_time_reset was called, the
>   pending statistics was incremented. If neither was called
>   and the timer is periodic, the pending statistics is
>   incremented when it is reloaded
>
>
> Signed-off-by: Vadim Suraev <vadim.suraev@gmail.com>
> ---
>   lib/librte_timer/rte_timer.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
> index 1ebd223..7035bed 100755
> --- a/lib/librte_timer/rte_timer.c
> +++ b/lib/librte_timer/rte_timer.c
> @@ -551,7 +551,7 @@ void rte_timer_manage(void)
>   		tim->f(tim, tim->arg);
>
>   		rte_spinlock_lock(&priv_timer[lcore_id].list_lock);
> -
> +		__TIMER_STAT_ADD(pending, -1);
>   		/* the timer was stopped or reloaded by the callback
>   		 * function, we have nothing to do here */
>   		if (priv_timer[lcore_id].updated == 1)
> @@ -559,7 +559,6 @@ void rte_timer_manage(void)
>
>   		if (tim->period == 0) {
>   			/* remove from done list and mark timer as stopped */
> -			__TIMER_STAT_ADD(pending, -1);
>   			status.state = RTE_TIMER_STOP;
>   			status.owner = RTE_TIMER_NO_OWNER;
>   			rte_wmb();
> @@ -568,6 +567,7 @@ void rte_timer_manage(void)
>   		else {
>   			/* keep it in list and mark timer as pending */
>   			status.state = RTE_TIMER_PENDING;
> +			__TIMER_STAT_ADD(pending, 1);
>   			status.owner = (int16_t)lcore_id;
>   			rte_wmb();
>   			tim->status.u32 = status.u32;
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [dpdk-dev] [PATCH] timer bug fix.
@ 2014-05-21 20:35 Vadim Suraev
  2014-05-23 14:44 ` Olivier MATZ
  0 siblings, 1 reply; 6+ messages in thread
From: Vadim Suraev @ 2014-05-21 20:35 UTC (permalink / raw)
  To: dev

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 called but then the pending
 statistics is additionally incremented so the timer is
 counted pending twice. 
Solution: decrement the pending
 statistics after returning from the callback. If
 rte_timer_stop was called, it skipped decrementing the
 pending statistics. If rte_time_reset was called, the
 pending statistics was incremented. If neither was called
 and the timer is periodic, the pending statistics is
 incremented when it is reloaded


Signed-off-by: Vadim Suraev <vadim.suraev@gmail.com>
---
 lib/librte_timer/rte_timer.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 1ebd223..7035bed 100755
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -551,7 +551,7 @@ void rte_timer_manage(void)
 		tim->f(tim, tim->arg);
 
 		rte_spinlock_lock(&priv_timer[lcore_id].list_lock);
-
+		__TIMER_STAT_ADD(pending, -1);
 		/* the timer was stopped or reloaded by the callback
 		 * function, we have nothing to do here */
 		if (priv_timer[lcore_id].updated == 1)
@@ -559,7 +559,6 @@ void rte_timer_manage(void)
 
 		if (tim->period == 0) {
 			/* remove from done list and mark timer as stopped */
-			__TIMER_STAT_ADD(pending, -1);
 			status.state = RTE_TIMER_STOP;
 			status.owner = RTE_TIMER_NO_OWNER;
 			rte_wmb();
@@ -568,6 +567,7 @@ void rte_timer_manage(void)
 		else {
 			/* keep it in list and mark timer as pending */
 			status.state = RTE_TIMER_PENDING;
+			__TIMER_STAT_ADD(pending, 1);
 			status.owner = (int16_t)lcore_id;
 			rte_wmb();
 			tim->status.u32 = status.u32;
-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-05-26 16:25 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-21 19:53 [dpdk-dev] [PATCH] timer bug fix Vadim Suraev
2014-05-23 14:52 ` Olivier MATZ
2014-05-26 16:24   ` Thomas Monjalon
2014-05-21 20:35 Vadim Suraev
2014-05-23 14:44 ` Olivier MATZ
2014-05-26 16:25   ` Thomas Monjalon

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).