> -----Original Message----- > From: David Marchand <david.march...@redhat.com> > Sent: Thursday, October 8, 2020 5:28 AM > To: Carrillo, Erik G <erik.g.carri...@intel.com> > Cc: dev@dpdk.org; sta...@dpdk.org; nd <n...@arm.com>; Honnappa > Nagarahalli <honnappa.nagaraha...@arm.com>; Sarosh Arif > <sarosh.a...@emumba.com> > 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 > <honnappa.nagaraha...@arm.com> 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: sta...@dpdk.org > > > > > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carri...@intel.com> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > > 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
