Re: [dpdk-dev] [PATCH v2 6/6] bbdev: reduce warning level for one scenario

["Chautru, Nicolas" <nicolas.chautru@intel.com>]

> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Sent: Wednesday, September 1, 2021 7:30 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> gakhil@marvell.com
> Cc: thomas@monjalon.net; hemant.agrawal@nxp.com; Zhang, Mingshan
> <mingshan.zhang@intel.com>; Joshi, Arun <arun.joshi@intel.com>
> Subject: Re: [PATCH v2 6/6] bbdev: reduce warning level for one scenario
> 
> 
> On 8/19/21 2:10 PM, Nicolas Chautru wrote:
> > Queue setup may genuinely fail when adding incremental queues for a
> > given priority level. In that case application would attempt to
> > configure a queue at a different priority level.
> > Not an actual error.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> >   lib/bbdev/rte_bbdev.c | 7 ++++---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
> > fc37236..defddcf 100644
> > --- a/lib/bbdev/rte_bbdev.c
> > +++ b/lib/bbdev/rte_bbdev.c
> > @@ -528,9 +528,10 @@ struct rte_bbdev *
> >   	ret = dev->dev_ops->queue_setup(dev, queue_id, (conf != NULL) ?
> >   			conf : &dev_info.default_queue_conf);
> >   	if (ret < 0) {
> > -		rte_bbdev_log(ERR,
> > -				"Device %u queue %u setup failed", dev_id,
> > -				queue_id);
> > +		/* This may happen when trying different priority levels */
> > +		rte_bbdev_log(INFO,
> > +				"Device %u queue %u setup failed",
> > +				dev_id, queue_id);
> 
> Earlier code tears down the exiting plumbing.
> 
> If it is ok to fail, should this block move earlier before the teardown ?

I may miss your point Tom.
If we reached that point at least there was nothing fundamental bad with the request which would have been reported as a formal error.
 At that point this may still be rejected because the provided priority bucket may genuinely be empty.
The code will handle it the same way as before (based on unchanged API) but at least we don't print an error string for something which may be reported as a failure on a routine sunny day scenario. 
Thanks

> 
> Tom
> 
> >   		return ret;
> >   	}
> >