> -----Original Message----- > From: David Marchand <[email protected]> > Sent: Thursday, October 8, 2020 5:28 AM > To: Carrillo, Erik G <[email protected]> > Cc: [email protected]; [email protected]; nd <[email protected]>; Honnappa > Nagarahalli <[email protected]>; Sarosh Arif > <[email protected]> > Subject: Re: [dpdk-dev] [PATCH 1/1] timer: add limitation note for sync stop > and reset > > On Thu, Sep 10, 2020 at 3:23 AM Honnappa Nagarahalli > <[email protected]> wrote: > > > If a timer's callback function calls rte_timer_reset_sync() or > > > rte_timer_stop_sync() on another timer that is in the RUNNING state > > > and owned by the current lcore, the *_sync() calls will loop indefinitely. > > > > > > Relatedly, if a timer's callback function calls *_sync() on another > > > timer that is in the RUNNING state and is owned by a different > > > lcore, but a timer callback function runs on that different lcore > > > and calls > > > *_sync() on a timer that is in the RUNNING state and owned by the > > > current lcore, the two lcores will loop indefinitely. > > > > > > Add a note in the rte_timer_stop_sync and rte_timer_reset_sync > > > documentation that indicates that these APIs should not be used > > > inside timer callback functions in order to avoid the hangs > > > described above, and suggests an alternative. > > > > > > Bugzilla ID: 491 > > > Cc: [email protected] > > > > > > Signed-off-by: Erik Gabriel Carrillo <[email protected]> > > Reviewed-by: Honnappa Nagarahalli <[email protected]> > > Applied, thanks. > > Since we go with documenting a limitation, should we mark the original > patches [1] and [2] as rejected instead of deferred? > > 1: https://patches.dpdk.org/patch/75156/ > 2: https://patches.dpdk.org/patch/73683/ > > Thanks, David.
Yes, those patches should be moved to "rejected" - I tried to do it myself, but got permission errors. Sarosh, can you make these updates? Thanks, Erik > -- > David Marchand
