Re: [dpdk-dev] [PATCH] common/qat: fix uninitialized variable bug

["Trahe, Fiona" <fiona.trahe@intel.com>]

> -----Original Message-----
> From: Dybkowski, AdamX <adamx.dybkowski@intel.com>
> Sent: Friday, July 24, 2020 12:58 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; akhil.goyal@nxp.com
> Subject: RE: [PATCH] common/qat: fix uninitialized variable bug
> 
> > -----Original Message-----
> > From: Trahe, Fiona <fiona.trahe@intel.com>
> > Sent: Friday, 24 July, 2020 13:55
> > To: Dybkowski, AdamX <adamx.dybkowski@intel.com>; dev@dpdk.org;
> > akhil.goyal@nxp.com
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: RE: [PATCH] common/qat: fix uninitialized variable bug
> >
> >
> >
> > > -----Original Message-----
> > > From: Dybkowski, AdamX <adamx.dybkowski@intel.com>
> > > Sent: Friday, July 24, 2020 10:40 AM
> > > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>;
> > > akhil.goyal@nxp.com
> > > Cc: Dybkowski, AdamX <adamx.dybkowski@intel.com>
> > > Subject: [PATCH] common/qat: fix uninitialized variable bug
> > >
> > > This patch fixes the uninitialized variable bug in QAT PMD.
> > >
> > > Fixes: 9f27a860dc16 ("crypto/qat: move generic qp function to qp
> > > file")
> > >
> > > Signed-off-by: Adam Dybkowski <adamx.dybkowski@intel.com>
> > > ---
> > >  drivers/common/qat/qat_qp.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/common/qat/qat_qp.c b/drivers/common/qat/qat_qp.c
> > > index aacd4ab21..0ee713955 100644
> > > --- a/drivers/common/qat/qat_qp.c
> > > +++ b/drivers/common/qat/qat_qp.c
> > > @@ -582,7 +582,7 @@ qat_enqueue_op_burst(void *qp, void **ops,
> > uint16_t nb_ops)
> > >  	register struct qat_queue *queue;
> > >  	struct qat_qp *tmp_qp = (struct qat_qp *)qp;
> > >  	register uint32_t nb_ops_sent = 0;
> > > -	register int ret;
> > > +	register int ret = -1;
> > Nack - this fn returns an unsigned. So the correct option is to default to 0
> 
> [Adam] The ret variable value (signed) is not returned directly, please check the rest of this function in src
> code. This is just checked to calculate how many ops were enqueued. And if all checks skip (meaning the
> op was not processed by sym crypto, asym crypto nor compression), we should note the user that the
> actual op was NOT enqueued. That's why ret is set to -1.
[Fiona] ok. makes sense thanks. In that case
Acked-by: Fiona Trahe <fiona.trahe@intel.com>