From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pablo.de.lara.guarch@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id 292801B30C
for <dev@dpdk.org>; Tue, 10 Oct 2017 15:43:49 +0200 (CEST)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
10 Oct 2017 06:43:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.42,505,1500966000"; d="scan'208";a="908530207"
Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153])
by FMSMGA003.fm.intel.com with ESMTP; 10 Oct 2017 06:43:34 -0700
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by
IRSMSX101.ger.corp.intel.com ([169.254.1.22]) with mapi id 14.03.0319.002;
Tue, 10 Oct 2017 14:43:34 +0100
From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: Akhil Goyal <akhil.goyal@nxp.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: "Doherty, Declan" <declan.doherty@intel.com>, "hemant.agrawal@nxp.com"
<hemant.agrawal@nxp.com>, "Nicolau, Radu" <radu.nicolau@intel.com>,
"borisp@mellanox.com" <borisp@mellanox.com>, "aviadye@mellanox.com"
<aviadye@mellanox.com>, "thomas@monjalon.net" <thomas@monjalon.net>,
"sandeep.malik@nxp.com" <sandeep.malik@nxp.com>,
"jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>,
"Mcnamara, John" <john.mcnamara@intel.com>, "Ananyev, Konstantin"
<konstantin.ananyev@intel.com>, "shahafs@mellanox.com"
<shahafs@mellanox.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>
Thread-Topic: [PATCH v3 03/12] cryptodev: support security APIs
Thread-Index: AQHTPs8GGijIyqMwD0KYy7G2FLbxZ6LdFo1Q
Date: Tue, 10 Oct 2017 13:43:33 +0000
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8976CC2F29D@IRSMSX108.ger.corp.intel.com>
References: <20171003131413.23846-1-akhil.goyal@nxp.com>
<20171006181151.4758-1-akhil.goyal@nxp.com>
<20171006181151.4758-4-akhil.goyal@nxp.com>
In-Reply-To: <20171006181151.4758-4-akhil.goyal@nxp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGNlYTMwOTEtYzUyMS00YTRiLWFmMGQtYzYxMjI0ZGQxZTY0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNi41LjkuMyIsIlRydXN0ZWRMYWJlbEhhc2giOiJNODhkZWpuMStzTXNmZU1CR0RsRTlpckxjTFpPdGQwOFRaOXZpQVdCcTJNPSJ9
x-ctpclassification: CTP_PUBLIC
dlp-product: dlpe-windows
dlp-version: 11.0.0.116
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 v3 03/12] cryptodev: support security APIs
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 13:43:50 -0000
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Friday, October 6, 2017 7:12 PM
> To: dev@dpdk.org
> Cc: Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; hemant.agrawal@nxp.com; Nicolau,
> Radu <radu.nicolau@intel.com>; borisp@mellanox.com;
> aviadye@mellanox.com; thomas@monjalon.net; sandeep.malik@nxp.com;
> jerin.jacob@caviumnetworks.com; Mcnamara, John
> <john.mcnamara@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; shahafs@mellanox.com;
> olivier.matz@6wind.com
> Subject: [PATCH v3 03/12] cryptodev: support security APIs
>=20
...
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index 327d7e8..7a7c936 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -488,6 +488,16 @@ rte_cryptodev_devices_get(const char
> *driver_name, uint8_t *devices,
> return count;
> }
>=20
> +uint16_t
> +rte_cryptodev_get_sec_id(uint8_t dev_id) {
> + if (rte_crypto_devices[dev_id].feature_flags &
> + RTE_CRYPTODEV_FF_SECURITY)
> + return rte_crypto_devices[dev_id].data->sec_id;
> +
> + return INVALID_SEC_ID;
Is this better than returning an integer?
>>From a user point of view, I see better to check for negative,
and other similar functions, such as rte_cryptodev_get_dev_id, return an in=
teger.
Thanks,
Pablo