[
> > Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in timer
> >
> > Thank you Eric, I will fix the mistakes in v2
> >
> > On Tue, Aug 4, 2020 at 4:16 AM Honnappa Nagarahalli
> > wrote:
> > >
> > >
> > >
> >
> -Original Message-
> From: Sarosh Arif
> Sent: Monday, August 3, 2020 10:29 PM
> To: Honnappa Nagarahalli ; Carrillo, Erik G
>
> Cc: rsanf...@akamai.com; dev@dpdk.org; nd
> Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in timer
>
> Thank you Er
Thank you Eric, I will fix the mistakes in v2
On Tue, Aug 4, 2020 at 4:16 AM Honnappa Nagarahalli
wrote:
>
>
>
> >
> > If the user tries to reset/stop some other timer in it's callback function,
> > which
> Is there any use case for this? Why not just say document that the user is
> not allowe
>
> If the user tries to reset/stop some other timer in it's callback function,
> which
Is there any use case for this? Why not just say document that the user is not
allowed to reset some other timer in the call back function? How does the user
get access to some other timer in the call back
> -Original Message-
> From: Sarosh Arif
> Sent: Monday, August 3, 2020 6:21 AM
> To: Carrillo, Erik G ; rsanf...@akamai.com
> Cc: dev@dpdk.org; Sarosh Arif
> Subject: [PATCH] doc: announce API change in timer
>
> If the user tries to reset/stop some other timer in it's callback function
If the user tries to reset/stop some other timer in it's callback
function, which is also about to expire, using
rte_timer_reset_sync/rte_timer_stop_sync the application goes into
an infinite loop. This happens because
rte_timer_reset_sync/rte_timer_stop_sync loop until the timer
resets/stops an
6 matches
Mail list logo
