DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Carrillo, Erik G" <erik.g.carrillo@intel.com>,
	Sarosh Arif <sarosh.arif@emumba.com>
Cc: "rsanford@akamai.com" <rsanford@akamai.com>,
	"dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in timer
Date: Tue, 4 Aug 2020 20:50:03 +0000
Message-ID: <DB6PR0802MB2216DAEB5994BE09AB0FB9CA984A0@DB6PR0802MB2216.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CY4PR1101MB21180DEFA589F691BCCF7065B94A0@CY4PR1101MB2118.namprd11.prod.outlook.com>

<snip>
[
> > 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
> > <Honnappa.Nagarahalli@arm.com> wrote:
> > >
> > > <snip>
> > >
> > > >
> > > > 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 function?
> > > Not sure if this was discussed earlier, I might have missed.
> > The issue is more clearly described in bug 491 here is a link:
> > https://bugs.dpdk.org/show_bug.cgi?id=491
> > further discussion on this issue was done on the following patch:
> > https://patches.dpdk.org/patch/73683/
Thanks for the links.

> >
> 
> I like Honnappa's suggestion... we could document that the *_sync functions
> shouldn't be used inside timer callbacks since there are cases where it could
> hang.  Instead, if doing this was desired, the regular versions could be used
> there, and the return values could be checked in that case.
Agree, non sync functions can be used.

> 
> > >
> > > > 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 and there is check inside timer_set_config_state
> > > > which prevents a running timer from being reset/stopped by not
> > > > it's own timer_cb. Therefore timer_set_config_state returns -1 due
> > > > to which rte_timer_reset returns -1 and rte_timer_reset_sync goes
> > > > into an infinite loop
> > > >
> > > > To to prevent this rte_timer_reset_sync and rte_timer_stop_sync
> > > > should have int return types, so that -1 can be returned if the
> > > > above condition occurs
> > > >
> > > > Signed-off-by: Sarosh Arif <sarosh.arif@emumba.com>
> > > > ---
> > > >  doc/guides/rel_notes/deprecation.rst | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > b/doc/guides/rel_notes/deprecation.rst
> > > > index ea4cfa7a4..ed93a707d 100644
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > @@ -151,3 +151,9 @@ Deprecation Notices
> > > >    Python 2 support will be completely removed in 20.11.
> > > >    In 20.08, explicit deprecation warnings will be displayed when running
> > > >    scripts with Python 2.
> > > > +
> > > > +* timer: Since timer can get stuck in an infinite loop if the
> > > > +application tries to
> > > > +  reset/stop some other timer in it's callback function, which is
> > > > +also about to
> > > > +  expire. The function ``rte_timer_stop_sync`` and
> > > > +``rte_timer_stop_sync``  will
> > > > +  have a int return type in order to return with -1 in when this
> > > > +condition
> > > > +  occures.
> > > > --
> > > > 2.17.1
> > >

  reply	other threads:[~2020-08-04 20:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 11:20 Sarosh Arif
2020-08-03 16:45 ` Carrillo, Erik G
2020-08-03 23:16 ` Honnappa Nagarahalli
2020-08-04  3:28   ` Sarosh Arif
2020-08-04 14:24     ` Carrillo, Erik G
2020-08-04 20:50       ` Honnappa Nagarahalli [this message]
2020-08-04  3:51 ` [dpdk-dev] [PATCH v2] " Sarosh Arif

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6PR0802MB2216DAEB5994BE09AB0FB9CA984A0@DB6PR0802MB2216.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=erik.g.carrillo@intel.com \
    --cc=nd@arm.com \
    --cc=rsanford@akamai.com \
    --cc=sarosh.arif@emumba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git