All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: dev@dpdk.org, bruce.richardson@intel.com,
	harry.van.haaren@intel.com, gage.eads@intel.com,
	nipun.gupta@nxp.com, narender.vangati@intel.com
Subject: Re: [PATCH] eventdev: define the default value for dequeue timeout
Date: Tue, 20 Jun 2017 21:18:03 +0530	[thread overview]
Message-ID: <20170620154801.GB8453@jerin> (raw)
In-Reply-To: <20170602143830.GA17430@jerin>

-----Original Message-----
> Date: Fri, 2 Jun 2017 20:08:30 +0530
> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> To: Hemant Agrawal <hemant.agrawal@nxp.com>
> Cc: dev@dpdk.org, bruce.richardson@intel.com, harry.van.haaren@intel.com,
>  gage.eads@intel.com, nipun.gupta@nxp.com, narender.vangati@intel.com
> Subject: Re: [PATCH] eventdev: define the default value for dequeue timeout
> User-Agent: Mutt/1.8.3 (2017-05-23)
> 
> -----Original Message-----
> > Date: Thu, 18 May 2017 19:45:44 +0530
> > From: Hemant Agrawal <hemant.agrawal@nxp.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, dev@dpdk.org
> > CC: bruce.richardson@intel.com, harry.van.haaren@intel.com,
> >  gage.eads@intel.com, nipun.gupta@nxp.com, narender.vangati@intel.com
> > Subject: Re: [PATCH] eventdev: define the default value for dequeue timeout
> > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
> >  Thunderbird/45.8.0
> > 
> > On 5/18/2017 2:18 PM, Jerin Jacob wrote:
> > > Defining the value 0 as default value for dequeue timeout
> > > will help the application reduce the configuration setup
> > > if the application is interested only in default
> > > timeout value.
> > > 
> > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > ---
> > > This patch will fix following error found in the event_pipeline RFC application
> > > http://dpdk.org/dev/patchwork/patch/23799/ with event_octeontx HW driver.
> > > 
> > > EVENTDEV: rte_event_dev_configure() line 379: dev0 invalid
> > > dequeue_timeout_ns=0 min_dequeue_timeout_ns=853 max_dequeue_timeout_ns=873813
> > > ---
> > >  drivers/event/octeontx/ssovf_evdev.c | 2 ++
> > >  lib/librte_eventdev/rte_eventdev.c   | 5 +++--
> > >  lib/librte_eventdev/rte_eventdev.h   | 1 +
> > >  3 files changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/event/octeontx/ssovf_evdev.c b/drivers/event/octeontx/ssovf_evdev.c
> > > index c80a44379..5499b1bf7 100644
> > > --- a/drivers/event/octeontx/ssovf_evdev.c
> > > +++ b/drivers/event/octeontx/ssovf_evdev.c
> > > @@ -194,6 +194,8 @@ ssovf_configure(const struct rte_eventdev *dev)
> > > 
> > >  	ssovf_func_trace();
> > >  	deq_tmo_ns = conf->dequeue_timeout_ns;
> > > +	if (deq_tmo_ns == 0)
> > > +		deq_tmo_ns = edev->min_deq_timeout_ns;
> > 
> > '0' should mean don't wait?
> 
> Yes. I think, we can leave that to the driver for the minimum supported
> dequeue timeout for the given platform(PMD). OCTEONTX PMD needs
> different treatment for "no-wait" case, hence setting the minimum value
> that PMD supports.
> 
> Any other comments on API change?

Let me know _if_ there is any objection to take this patch?

> 
> 
> > 
> > > 
> > >  	if (conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT) {
> > >  		edev->is_timeout_deq = 1;
> > > diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
> > > index 20afc3f0e..8cafffe03 100644
> > > --- a/lib/librte_eventdev/rte_eventdev.c
> > > +++ b/lib/librte_eventdev/rte_eventdev.c
> > > @@ -369,9 +369,10 @@ rte_event_dev_configure(uint8_t dev_id,
> > > 
> > >  	/* Check dequeue_timeout_ns value is in limit */
> > >  	if (!(dev_conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT)) {
> > > -		if (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
> > > +		if (dev_conf->dequeue_timeout_ns &&
> > > +		    (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
> > >  			|| dev_conf->dequeue_timeout_ns >
> > > -				 info.max_dequeue_timeout_ns) {
> > > +				 info.max_dequeue_timeout_ns)) {
> > >  			RTE_EDEV_LOG_ERR("dev%d invalid dequeue_timeout_ns=%d"
> > >  			" min_dequeue_timeout_ns=%d max_dequeue_timeout_ns=%d",
> > >  			dev_id, dev_conf->dequeue_timeout_ns,
> > > diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
> > > index 94284337d..f39fbc6b9 100644
> > > --- a/lib/librte_eventdev/rte_eventdev.h
> > > +++ b/lib/librte_eventdev/rte_eventdev.h
> > > @@ -409,6 +409,7 @@ struct rte_event_dev_config {
> > >  	 * This value should be in the range of *min_dequeue_timeout_ns* and
> > >  	 * *max_dequeue_timeout_ns* which previously provided in
> > >  	 * rte_event_dev_info_get()
> > > +	 * The value 0 is allowed, in which case, default dequeue timeout used.
> > >  	 * @see RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT
> > >  	 */
> > >  	int32_t nb_events_limit;
> > > 
> > 
> > 

  reply	other threads:[~2017-06-20 15:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18  8:48 [PATCH] eventdev: define the default value for dequeue timeout Jerin Jacob
2017-05-18 14:15 ` Hemant Agrawal
2017-06-02 14:38   ` Jerin Jacob
2017-06-20 15:48     ` Jerin Jacob [this message]
2017-06-21 11:38       ` Jerin Jacob

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=20170620154801.GB8453@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=narender.vangati@intel.com \
    --cc=nipun.gupta@nxp.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.