From: Hemant Agrawal <hemant.agrawal@nxp.com>
To: Akhil Goyal <akhil.goyal@nxp.com>,
Radu Nicolau <radu.nicolau@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"declan.doherty@intel.com" <declan.doherty@intel.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"aviadye@mellanox.com" <aviadye@mellanox.com>,
"borisp@mellanox.com" <borisp@mellanox.com>,
"pablo.de.lara.guarch@intel.com" <pablo.de.lara.guarch@intel.com>,
"sergio.gonzalez.monroy@intel.com"
<sergio.gonzalez.monroy@intel.com>
Cc: Sandeep Malik <sandeep.malik@nxp.com>,
"techboard@dpdk.org" <techboard@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 1/4] rte_security: API definitions
Date: Wed, 16 Aug 2017 15:40:12 +0000 [thread overview]
Message-ID: <AM2PR04MB075365F0374B7F006106BB1489820@AM2PR04MB0753.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <4cee6900-f886-6997-6911-6c9ca1735e65@nxp.com>
Hi Thomas,
Can we get a next-security tree to do development around this proposal?
Also, we can discuss about this proposal in general in next techboard meeting.
Regards,
Hemant
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, August 16, 2017 1:10 PM
> To: Radu Nicolau <radu.nicolau@intel.com>; dev@dpdk.org;
> declan.doherty@intel.com; thomas@monjalon.net;
> aviadye@mellanox.com; borisp@mellanox.com;
> pablo.de.lara.guarch@intel.com; sergio.gonzalez.monroy@intel.com
> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; Sandeep Malik
> <sandeep.malik@nxp.com>
> Subject: Re: [RFC PATCH 1/4] rte_security: API definitions
>
> On 8/15/2017 4:34 PM, Radu Nicolau wrote:
> >
> > On 8/15/2017 7:35 AM, Akhil Goyal wrote:
> >> Detailed description is added in the coverletter
> >>
> >> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> >> ---
> >> lib/librte_cryptodev/rte_security.c | 171 +++++++++++++++
> >> lib/librte_cryptodev/rte_security.h | 409
> >> ++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 580 insertions(+)
> >> create mode 100644 lib/librte_cryptodev/rte_security.c
> >> create mode 100644 lib/librte_cryptodev/rte_security.h
> >>
>
> >> +int
> >> +rte_security_session_init(uint16_t dev_id,
> >> + struct rte_security_session *sess,
> >> + struct rte_security_sess_conf *conf,
> >> + struct rte_mempool *mp) {
> >> + struct rte_cryptodev *cdev = NULL;
> >> + struct rte_eth_dev *dev = NULL;
> >> + uint8_t index;
> >> + int ret;
> >> +
> >> + if (sess == NULL || conf == NULL)
> >> + return -EINVAL;
> >> +
> >> + switch (conf->action_type) {
> >> + case RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD:
> >> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
> >> + return -EINVAL;
> >> + cdev = rte_cryptodev_pmd_get_dev(dev_id);
> >> + index = cdev->driver_id;
> >> + if (sess->sess_private_data[index] == NULL) {
> >> + ret = cdev->sec_ops->session_configure(cdev, conf, sess,
> >> mp);
> >> + if (ret < 0) {
> >> + CDEV_LOG_ERR(
> >> + "cdev_id %d failed to configure session details",
> >> + dev_id);
> >> + return ret;
> >> + }
> >> + }
> >> + break;
> >> + case RTE_SECURITY_SESS_ETH_INLINE_CRYPTO:
> >> + case RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD:
> >> + dev = &rte_eth_devices[dev_id];
> >> + index = dev->data->port_id;
> >> + if (sess->sess_private_data[index] == NULL) {
> >> +// ret = dev->sec_ops->session_configure(dev, conf, sess,
> >> mp);
> >> +// if (ret < 0) {
> >> +// CDEV_LOG_ERR(
> >> +// "dev_id %d failed to configure session details",
> >> +// dev_id);
> >> +// return ret;
> >> +// }
> > The commented lines above suggests that also eth devices will have a
> > sec_ops field, (which makes sense). Is this correct?
> > Also, if the above is correct, session_configure and session_clear
> > should accept both crypto and eth devices as first parameter.
>
> Yes you are correct both these ops should accept void *dev and internally in
> the driver should typecast to respective device.
> Please consider the following diff over this patch
>
>
> diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
> b/lib/librte_cryptodev/rte_cryptodev_pmd.h
> index 219fba6..ab3ecf7 100644
> --- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
> +++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
> @@ -371,7 +371,7 @@ struct rte_cryptodev_ops {
> * - Returns -ENOTSUP if crypto device does not support the crypto
> transform.
> * - Returns -ENOMEM if the private session could not be allocated.
> */
> -typedef int (*security_configure_session_t)(struct rte_cryptodev *dev,
> +typedef int (*security_configure_session_t)(void *dev,
> struct rte_security_sess_conf *conf,
> struct rte_security_session *sess,
> struct rte_mempool *mp);
> @@ -382,7 +382,7 @@ typedef int (*security_configure_session_t)(struct
> rte_cryptodev *dev,
> * @param dev Crypto device pointer
> * @param sess Security session structure
> */
> -typedef void (*security_free_session_t)(struct rte_cryptodev *dev,
> +typedef void (*security_free_session_t)(void *dev,
> struct rte_security_session *sess);
>
> /** Security operations function pointer table */
> diff --git a/lib/librte_cryptodev/rte_security.c
> b/lib/librte_cryptodev/rte_security.c
> index 7c73c93..a7558bb 100644
> --- a/lib/librte_cryptodev/rte_security.c
> +++ b/lib/librte_cryptodev/rte_security.c
> @@ -87,7 +87,8 @@ rte_security_session_init(uint16_t dev_id,
> cdev = rte_cryptodev_pmd_get_dev(dev_id);
> index = cdev->driver_id;
> if (sess->sess_private_data[index] == NULL) {
> - ret = cdev->sec_ops->session_configure(cdev,
> conf, sess, mp);
> + ret = cdev->sec_ops->session_configure((void *)cdev,
> + conf, sess, mp);
> if (ret < 0) {
> CDEV_LOG_ERR(
> "cdev_id %d failed to configure
> session details",
> @@ -101,7 +102,8 @@ rte_security_session_init(uint16_t dev_id,
> dev = &rte_eth_devices[dev_id];
> index = dev->data->port_id;
> if (sess->sess_private_data[index] == NULL) {
> -// ret = dev->sec_ops->session_configure(dev, conf,
> sess, mp);
> +// ret = dev->sec_ops->session_configure((void *)dev,
> +// conf, sess, mp);
>
> Thanks,
> Akhil
next prev parent reply other threads:[~2017-08-16 15:40 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 7:35 [dpdk-dev] [RFC 0/7] ipsec inline Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 1/7] ethdev: add device ipsec encrypt/decrypt capability flags Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 2/7] ethdev: Add ESP header to generic flow steering Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 3/7] ethdev: add rte flow action for crypto Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 4/7] cryptodev: add ipsec xform Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 5/7] mbuf: Add IPsec crypto flags Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 6/7] mbuf: Added next_esp_proto field Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 7/7] example/ipsec_gw: Support SA offload in datapath Boris Pismenny
2017-07-11 17:06 ` [dpdk-dev] [RFC 0/7] ipsec inline Declan Doherty
2017-07-12 14:08 ` Boris Pismenny
2017-07-14 11:12 ` Akhil Goyal
2017-07-25 11:21 ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Akhil Goyal
2017-07-25 11:21 ` [dpdk-dev] [RFC PATCH 1/1] rte_security: proposal Akhil Goyal
2017-07-26 13:46 ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Declan Doherty
2017-08-02 13:16 ` Hemant Agrawal
2017-08-03 11:25 ` Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH v2 0/4] " Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 1/4] rte_security: API definitions Akhil Goyal
2017-08-15 11:04 ` Radu Nicolau
2017-08-16 7:39 ` Akhil Goyal
2017-08-16 15:40 ` Hemant Agrawal [this message]
2017-08-18 9:16 ` Thomas Monjalon
2017-08-18 12:20 ` Hemant Agrawal
2017-08-21 10:32 ` Boris Pismenny
2017-08-21 10:54 ` Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 2/4] cryptodev: entend cryptodev to support security APIs Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 3/4] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 4/4] example/ipsec-secgw: add support for offloading crypto op Akhil Goyal
2017-08-29 14:49 ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Thomas Monjalon
2017-08-31 9:37 ` Akhil Goyal
2017-08-31 10:06 ` Thomas Monjalon
2017-08-31 10:52 ` Akhil Goyal
2017-08-31 13:14 ` Thomas Monjalon
2017-08-31 14:09 ` Radu Nicolau
2017-09-06 15:53 ` Jerin Jacob
2017-09-08 11:12 ` Akhil Goyal
2017-09-11 18:10 ` 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=AM2PR04MB075365F0374B7F006106BB1489820@AM2PR04MB0753.eurprd04.prod.outlook.com \
--to=hemant.agrawal@nxp.com \
--cc=akhil.goyal@nxp.com \
--cc=aviadye@mellanox.com \
--cc=borisp@mellanox.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=pablo.de.lara.guarch@intel.com \
--cc=radu.nicolau@intel.com \
--cc=sandeep.malik@nxp.com \
--cc=sergio.gonzalez.monroy@intel.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).