From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id C29323250 for ; Tue, 11 Jul 2017 16:08:58 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 07:08:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,346,1496127600"; d="scan'208";a="125767016" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga006.fm.intel.com with ESMTP; 11 Jul 2017 07:08:29 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX104.ger.corp.intel.com ([169.254.5.26]) with mapi id 14.03.0319.002; Tue, 11 Jul 2017 15:08:28 +0100 From: "De Lara Guarch, Pablo" To: Pavan Nikhilesh Bhagavatula , "dev@dpdk.org" , "Trahe, Fiona" CC: "Doherty, Declan" Thread-Topic: [dpdk-dev] [PATCH] cryptodev: fix cryptodev start return value Thread-Index: AQHS36ZzMWjjL4JjFkGBkX/yTqgsKqIajfGAgDRQriA= Date: Tue, 11 Jul 2017 14:08:28 +0000 Message-ID: References: <1496831804-28265-1-git-send-email-pbhagavatula@caviumnetworks.com> <348A99DA5F5B7549AA880327E580B43589219317@IRSMSX101.ger.corp.intel.com> <20170608081242.GA19599@PBHAGAVATULA-LT> In-Reply-To: <20170608081242.GA19599@PBHAGAVATULA-LT> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix cryptodev start return value X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 14:08:59 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pavan Nikhilesh > Bhagavatula > Sent: Thursday, June 8, 2017 9:13 AM > To: dev@dpdk.org; Trahe, Fiona > Cc: Doherty, Declan ; Pavan Nikhilesh > > Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix cryptodev start return val= ue >=20 > On Wed, Jun 07, 2017 at 03:54:23PM +0000, Trahe, Fiona wrote: > > Hi Pavan, > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pavan > Nikhilesh > > > Sent: Wednesday, June 7, 2017 11:37 AM > > > To: dev@dpdk.org > > > Cc: Doherty, Declan ; Pavan Nikhilesh > > > Bhagavatula > > > Subject: [dpdk-dev] [PATCH] cryptodev: fix cryptodev start return > > > value > > > > > > From: Pavan Nikhilesh Bhagavatula > > > > > > > If cryptodev has already started it should return -EBUSY instead of > > > 0 when rte_cryptodev_start is called. > > > > > > Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for > > > crypto devices") > > > > > > Signed-off-by: Pavan Nikhilesh > > > --- > > > lib/librte_cryptodev/rte_cryptodev.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > > > b/lib/librte_cryptodev/rte_cryptodev.c > > > index b65cd9c..c815038 100644 > > > --- a/lib/librte_cryptodev/rte_cryptodev.c > > > +++ b/lib/librte_cryptodev/rte_cryptodev.c > > > @@ -1000,7 +1000,7 @@ rte_cryptodev_start(uint8_t dev_id) > > > if (dev->data->dev_started !=3D 0) { > > > CDEV_LOG_ERR("Device with dev_id=3D%" PRIu8 " already > started", > > > dev_id); > > > - return 0; > > > + return -EBUSY; > > It makes sense to me to return 0/success in this case, as the end > > result is the same, the device is successfully started. > > But I don't feel strongly about it if there's a good argument for makin= g the > change? >=20 > I do agree with this but from an application perspective when the API is > called again after the device has already started (without calling the st= op > API) it would mean that there is an underlying issue with the application= 's > business logic and it would go undetected, so I feel that we should stric= tly > enforce this scenario as an error. >=20 > > However, as it is an API change doesn't it need to be flagged in a rele= ase > before the change is made? >=20 > I don't think that this would be an API change as it doesn't deprecate th= e > existing ABI. > Any thoughts about this from the community are welcome as the same > issue affects multiple core libraries (crytodev, ethdev, eventdev). Hi Pavan, As said by Fiona and Thomas (for ethdev), this is an API change, so it woul= d require a deprecation notice, in order to be changed in the next release. Thanks, Pablo > > > > > > } > > > > > > diag =3D (*dev->dev_ops->dev_start)(dev); > > > -- > > > 2.7.4 > >