Yes, this change makes sense. I ran timer tests and they passed.
Acked-by: Robert Sanford <rsanford at akamai.com>
Thanks,
Robert
On 9/29/16, 10:27 AM, "Karmarkar Suyash" <skarmarkar at sonusnet.com> wrote:
Hello,
Can you please review the changes and suggest next steps? Thanks
Regards
Suyash Karmarkar
-----Original Message-----
From: Karmarkar Suyash
Sent: Wednesday, September 21, 2016 4:54 PM
To: dev at dpdk.org; thomas.monjalon at 6wind.com; rsanford at akamai.com;
reshma.pattan at intel.com
Cc: Karmarkar Suyash <skarmarkar at sonusnet.com>
Subject: [PATCH v2]:rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code
added additional delay when the next peridoc timer was initialized
by not taking into account the delay added, with this fix the code
would start the next occurrence of timer keeping in account the
lag added.Corrected the behavior.
Fixes: 9b15ba89 ("timer: use a skip list")
Karmarkar Suyash (1):
Signed-off-by: Karmarkar Suyash <skarmarkar at sonusnet.com>
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
- __rte_timer_reset(tim, cur_time + tim->period,
+ __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(&priv_timer[lcore_id].list_lock);
}
--
2.9.3.windows.1
