diff mbox series

examples/timer: fix incorrect time interval

Message ID 1618470748-12369-1-git-send-email-humin29@huawei.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series examples/timer: fix incorrect time interval |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/travis-robot success travis build: passed
ci/github-robot success github build: passed
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-testing success Testing PASS

Commit Message

humin (Q) April 15, 2021, 7:12 a.m. UTC 
  From: Chengchang Tang <tangchengchang@huawei.com>

Timer sample example assumes that the frequency of the timer is about
2Ghz to control the period of calling rte_timer_manage(). But this
assumption is easy to fail. For example. the frequency of tsc on ARM64
is much less than 2Ghz.

This patch uses the frequency of the current timer to calculate the
correct time interval to ensure consistent result on all platforms.

In addition, the rte_rdtsc() is replaced with the more recommended
rte_get_timer_cycles function in this patch.

Fixes: af75078fece3 ("first public release")
Cc: stable@dpdk.org

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
---
 examples/timer/main.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

Comments

Thomas Monjalon April 21, 2021, 6:34 p.m. UTC | #1 
15/04/2021 09:12, Min Hu (Connor):
> From: Chengchang Tang <tangchengchang@huawei.com>
> 
> Timer sample example assumes that the frequency of the timer is about
> 2Ghz to control the period of calling rte_timer_manage(). But this
> assumption is easy to fail. For example. the frequency of tsc on ARM64
> is much less than 2Ghz.

So rte_timer_manage() will be called less often, yes.

> This patch uses the frequency of the current timer to calculate the
> correct time interval to ensure consistent result on all platforms.

I am not sure about making the example more complex.
What is the issue with the previous value?
Carrillo, Erik G April 21, 2021, 7:12 p.m. UTC | #2 
> -----Original Message-----
> From: Min Hu (Connor) <humin29@huawei.com>
> Sent: Thursday, April 15, 2021 2:12 AM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; rsanford@akamai.com; Carrillo,
> Erik G <erik.g.carrillo@intel.com>
> Subject: [PATCH] examples/timer: fix incorrect time interval
> 
> From: Chengchang Tang <tangchengchang@huawei.com>
> 
> Timer sample example assumes that the frequency of the timer is about
> 2Ghz to control the period of calling rte_timer_manage(). But this
> assumption is easy to fail. For example. the frequency of tsc on ARM64 is
> much less than 2Ghz.
> 
> This patch uses the frequency of the current timer to calculate the correct
> time interval to ensure consistent result on all platforms.
> 
> In addition, the rte_rdtsc() is replaced with the more recommended
> rte_get_timer_cycles function in this patch.
> 
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>

This LGTM - thanks.

Acked-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
Chengchang Tang April 22, 2021, 1:38 a.m. UTC | #3 
Hi
On 2021/4/22 2:34, Thomas Monjalon wrote:
> 15/04/2021 09:12, Min Hu (Connor):
>> From: Chengchang Tang <tangchengchang@huawei.com>
>>
>> Timer sample example assumes that the frequency of the timer is about
>> 2Ghz to control the period of calling rte_timer_manage(). But this
>> assumption is easy to fail. For example. the frequency of tsc on ARM64
>> is much less than 2Ghz.
> 
> So rte_timer_manage() will be called less often, yes.
> 
>> This patch uses the frequency of the current timer to calculate the
>> correct time interval to ensure consistent result on all platforms.
> 
> I am not sure about making the example more complex.
> What is the issue with the previous value?
>
In my understanding, the example should illustrate the standard usage of
related functions. Some of our customers did not know the difference in
tsc frequency between arm and x86 when using our SoC. As a result, some
misunderstanding are caused. So I think I could explain a more general
approach in the example, which will help these new users. When using a
timer, we must first know its frequency.  So I've added a frequency
acquisition process to the example, so that new users can realize that
there are differences between different platforms, so that they can design
more general programs.

>
> 
> 
> .
>
Thomas Monjalon May 5, 2021, 9:37 p.m. UTC | #4 
15/04/2021 09:12, Min Hu (Connor):
> From: Chengchang Tang <tangchengchang@huawei.com>
> 
> Timer sample example assumes that the frequency of the timer is about
> 2Ghz to control the period of calling rte_timer_manage(). But this
> assumption is easy to fail. For example. the frequency of tsc on ARM64
> is much less than 2Ghz.
> 
> This patch uses the frequency of the current timer to calculate the
> correct time interval to ensure consistent result on all platforms.
> 
> In addition, the rte_rdtsc() is replaced with the more recommended
> rte_get_timer_cycles function in this patch.
> 
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
[...]
>  		/*
> -		 * Call the timer handler on each core: as we don't
> -		 * need a very precise timer, so only call
> -		 * rte_timer_manage() every ~10ms (at 2Ghz). In a real
> -		 * application, this will enhance performances as
> -		 * reading the HPET timer is not efficient.
> +		 * Call the timer handler on each core: as we don't need a
> +		 * very precise timer, so only call rte_timer_manage()
> +		 * every ~10ms. since rte_eal_hpet_init() has not been
> +		 * called, the rte_rdtsc() will be used at runtime.

I don't understand this last sentence.

> +		 * In a real application, this will enhance performances
> +		 * as reading the HPET timer is not efficient.
>  		 */
> -		cur_tsc = rte_rdtsc();
> +		cur_tsc = rte_get_timer_cycles();
Chengchang Tang May 6, 2021, 2:06 a.m. UTC | #5 
On 2021/5/6 5:37, Thomas Monjalon wrote:
> 15/04/2021 09:12, Min Hu (Connor):
>> From: Chengchang Tang <tangchengchang@huawei.com>
>>
>> Timer sample example assumes that the frequency of the timer is about
>> 2Ghz to control the period of calling rte_timer_manage(). But this
>> assumption is easy to fail. For example. the frequency of tsc on ARM64
>> is much less than 2Ghz.
>>
>> This patch uses the frequency of the current timer to calculate the
>> correct time interval to ensure consistent result on all platforms.
>>
>> In addition, the rte_rdtsc() is replaced with the more recommended
>> rte_get_timer_cycles function in this patch.
>>
>> Fixes: af75078fece3 ("first public release")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
> [...]
>>  		/*
>> -		 * Call the timer handler on each core: as we don't
>> -		 * need a very precise timer, so only call
>> -		 * rte_timer_manage() every ~10ms (at 2Ghz). In a real
>> -		 * application, this will enhance performances as
>> -		 * reading the HPET timer is not efficient.
>> +		 * Call the timer handler on each core: as we don't need a
>> +		 * very precise timer, so only call rte_timer_manage()
>> +		 * every ~10ms. since rte_eal_hpet_init() has not been
>> +		 * called, the rte_rdtsc() will be used at runtime.
> 
> I don't understand this last sentence.
> 

This is explaining why we can use rte_get_timer_cycles() instead of rte_rdtsc().
In this example, we call tsc to improve its performance. So, we invoked rte_rdtsc()
here. Now the function rte_get_timer_cycles() encapsulates these counters. It will
invoke the corresponding counter according to the user's initialization of the counter.

>> +		 * In a real application, this will enhance performances
>> +		 * as reading the HPET timer is not efficient.
>>  		 */
>> -		cur_tsc = rte_rdtsc();
>> +		cur_tsc = rte_get_timer_cycles();
> 
> 
> 
> 
> .
>
Thomas Monjalon May 6, 2021, 8:08 a.m. UTC | #6 
06/05/2021 04:06, Chengchang Tang:
> 
> On 2021/5/6 5:37, Thomas Monjalon wrote:
> > 15/04/2021 09:12, Min Hu (Connor):
> >> From: Chengchang Tang <tangchengchang@huawei.com>
> >>
> >> Timer sample example assumes that the frequency of the timer is about
> >> 2Ghz to control the period of calling rte_timer_manage(). But this
> >> assumption is easy to fail. For example. the frequency of tsc on ARM64
> >> is much less than 2Ghz.
> >>
> >> This patch uses the frequency of the current timer to calculate the
> >> correct time interval to ensure consistent result on all platforms.
> >>
> >> In addition, the rte_rdtsc() is replaced with the more recommended
> >> rte_get_timer_cycles function in this patch.
> >>
> >> Fixes: af75078fece3 ("first public release")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> >> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
> > [...]
> >>  		/*
> >> -		 * Call the timer handler on each core: as we don't
> >> -		 * need a very precise timer, so only call
> >> -		 * rte_timer_manage() every ~10ms (at 2Ghz). In a real
> >> -		 * application, this will enhance performances as
> >> -		 * reading the HPET timer is not efficient.
> >> +		 * Call the timer handler on each core: as we don't need a
> >> +		 * very precise timer, so only call rte_timer_manage()
> >> +		 * every ~10ms. since rte_eal_hpet_init() has not been
> >> +		 * called, the rte_rdtsc() will be used at runtime.
> > 
> > I don't understand this last sentence.
> > 
> 
> This is explaining why we can use rte_get_timer_cycles() instead of rte_rdtsc().
> In this example, we call tsc to improve its performance. So, we invoked rte_rdtsc()
> here. Now the function rte_get_timer_cycles() encapsulates these counters. It will
> invoke the corresponding counter according to the user's initialization of the counter.

That's very confusing. Better to drop.

> 
> >> +		 * In a real application, this will enhance performances
> >> +		 * as reading the HPET timer is not efficient.
> >>  		 */
> >> -		cur_tsc = rte_rdtsc();
> >> +		cur_tsc = rte_get_timer_cycles();
Chengchang Tang May 6, 2021, 8:23 a.m. UTC | #7 
On 2021/5/6 16:08, Thomas Monjalon wrote:
> 06/05/2021 04:06, Chengchang Tang:
>>
>> On 2021/5/6 5:37, Thomas Monjalon wrote:
>>> 15/04/2021 09:12, Min Hu (Connor):
>>>> From: Chengchang Tang <tangchengchang@huawei.com>
>>>>
>>>> Timer sample example assumes that the frequency of the timer is about
>>>> 2Ghz to control the period of calling rte_timer_manage(). But this
>>>> assumption is easy to fail. For example. the frequency of tsc on ARM64
>>>> is much less than 2Ghz.
>>>>
>>>> This patch uses the frequency of the current timer to calculate the
>>>> correct time interval to ensure consistent result on all platforms.
>>>>
>>>> In addition, the rte_rdtsc() is replaced with the more recommended
>>>> rte_get_timer_cycles function in this patch.
>>>>
>>>> Fixes: af75078fece3 ("first public release")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
>>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>> [...]
>>>>  		/*
>>>> -		 * Call the timer handler on each core: as we don't
>>>> -		 * need a very precise timer, so only call
>>>> -		 * rte_timer_manage() every ~10ms (at 2Ghz). In a real
>>>> -		 * application, this will enhance performances as
>>>> -		 * reading the HPET timer is not efficient.
>>>> +		 * Call the timer handler on each core: as we don't need a
>>>> +		 * very precise timer, so only call rte_timer_manage()
>>>> +		 * every ~10ms. since rte_eal_hpet_init() has not been
>>>> +		 * called, the rte_rdtsc() will be used at runtime.
>>>
>>> I don't understand this last sentence.
>>>
>>
>> This is explaining why we can use rte_get_timer_cycles() instead of rte_rdtsc().
>> In this example, we call tsc to improve its performance. So, we invoked rte_rdtsc()
>> here. Now the function rte_get_timer_cycles() encapsulates these counters. It will
>> invoke the corresponding counter according to the user's initialization of the counter.
> 
> That's very confusing. Better to drop.
> 
OK, I will remove this sentence in the next version.
>>
>>>> +		 * In a real application, this will enhance performances
>>>> +		 * as reading the HPET timer is not efficient.
>>>>  		 */
>>>> -		cur_tsc = rte_rdtsc();
>>>> +		cur_tsc = rte_get_timer_cycles();
> 
> 
> 
> 
> .
>
diff mbox series

Patch

diff --git a/examples/timer/main.c b/examples/timer/main.c
index 5a57e48..05f4a9f 100644
--- a/examples/timer/main.c
+++ b/examples/timer/main.c
@@ -18,8 +18,7 @@ 
 #include <rte_timer.h>
 #include <rte_debug.h>
 
-#define TIMER_RESOLUTION_CYCLES 20000000ULL /* around 10ms at 2 Ghz */
-
+static uint64_t timer_resolution_cycles;
 static struct rte_timer timer0;
 static struct rte_timer timer1;
 
@@ -66,15 +65,16 @@  lcore_mainloop(__rte_unused void *arg)
 
 	while (1) {
 		/*
-		 * Call the timer handler on each core: as we don't
-		 * need a very precise timer, so only call
-		 * rte_timer_manage() every ~10ms (at 2Ghz). In a real
-		 * application, this will enhance performances as
-		 * reading the HPET timer is not efficient.
+		 * Call the timer handler on each core: as we don't need a
+		 * very precise timer, so only call rte_timer_manage()
+		 * every ~10ms. since rte_eal_hpet_init() has not been
+		 * called, the rte_rdtsc() will be used at runtime.
+		 * In a real application, this will enhance performances
+		 * as reading the HPET timer is not efficient.
 		 */
-		cur_tsc = rte_rdtsc();
+		cur_tsc = rte_get_timer_cycles();
 		diff_tsc = cur_tsc - prev_tsc;
-		if (diff_tsc > TIMER_RESOLUTION_CYCLES) {
+		if (diff_tsc > timer_resolution_cycles) {
 			rte_timer_manage();
 			prev_tsc = cur_tsc;
 		}
@@ -100,8 +100,10 @@  main(int argc, char **argv)
 	rte_timer_init(&timer0);
 	rte_timer_init(&timer1);
 
-	/* load timer0, every second, on main lcore, reloaded automatically */
 	hz = rte_get_timer_hz();
+	timer_resolution_cycles = hz * 10 / 1000; /* around 10ms */
+
+	/* load timer0, every second, on main lcore, reloaded automatically */
 	lcore_id = rte_lcore_id();
 	rte_timer_reset(&timer0, hz, PERIODICAL, lcore_id, timer0_cb, NULL);