DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Coyle, David" <david.coyle@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	"Zhang, Roy Fan" <roy.fan.zhang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Ryan, Brendan" <brendan.ryan@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"anoobj@marvell.com" <anoobj@marvell.com>,
	"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
	"lironh@marvell.com" <lironh@marvell.com>,
	"rnagadheeraj@marvell.com" <rnagadheeraj@marvell.com>,
	"jsrikanth@marvell.com" <jsrikanth@marvell.com>,
	"G.Singh@nxp.com" <G.Singh@nxp.com>,
	"jianjay.zhou@huawei.com" <jianjay.zhou@huawei.com>,
	"ravi1.kumar@amd.com" <ravi1.kumar@amd.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"alexr@mellanox.com" <alexr@mellanox.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"O'loingsigh, Mairtin" <mairtin.oloingsigh@intel.com>
Subject: Re: [dpdk-dev] [PATCH 2/3] cryptodev: add security operation to crypto	operation
Date: Thu, 11 Jun 2020 14:01:12 +0000	[thread overview]
Message-ID: <MN2PR11MB3550B4F23C2D162CA0DA68DEE3800@MN2PR11MB3550.namprd11.prod.outlook.com> (raw)
In-Reply-To: <BYAPR11MB33015D16EE475FF654ECFFDF9A800@BYAPR11MB3301.namprd11.prod.outlook.com>

Hi Konstantin,

> > > > >
> > > > > >
> > > > > >  /** Status of crypto operation */ @@ -121,6 +123,13 @@ struct
> > > > > > rte_crypto_op {
> > > > > >  		struct rte_crypto_asym_op asym[0];
> > > > > >  		/**< Asymmetric operation parameters */
> > > > > >
> > > > > > +#ifdef RTE_LIBRTE_SECURITY
> > > > > > +		uint8_t security[0];
> > > > > > +		/**< Security operation parameters
> > > > > > +		 * - Must be accessed through a rte_security_op
> pointer
> > > > > > +		 */
> > > > > > +#endif
> > > > > > +
> > > > > >  	}; /**< operation specific parameters */  };
> > > > >
> > > > > Is there any point to have this extra level of indirection?
> > > > > Might be simply:
> > > > >
> > > > > enum rte_crypto_op_type {
> > > > > 	....
> > > > > +	RTE_CRYPTO_OP_TYPE_SEC_DOCSIS,
> > > > > };
> > > > > ...
> > > > > struct rte_crypto_op {
> > > > > 	....
> > > > > 	__extension__
> > > > >         union {
> > > > >                 struct rte_crypto_sym_op sym[0];
> > > > >                 /**< Symmetric operation parameters */
> > > > >
> > > > >                 struct rte_crypto_asym_op asym[0];
> > > > >                 /**< Asymmetric operation parameters */
> > > > >
> > > > > +	struct rte_security_docsis_op docsis[0];
> > > > >
> > > > >         }; /**< operation specific parameters */
> > > > >
> > > > > ?
> > > > [DC] This was to allow some form of extensibility and not to limit
> > > > this to just
> > > DOCSIS.
> > > > If it's felt that having the extra level of indirection is
> > > > overkill, it can be easily
> > > changed.
> > > >
> > > > However, we cannot include a struct of type 'struct
> > > > rte_security_docsis_op' (or 'struct rte_security_op') directly
> > > > here, without creating nasty circular dependency of includes
> > > > between
> > > rte_cryptodev and rte_security.
> > > >
> > > > I had tried defining an opaque version 'struct rte_security_op' (i.e.
> > > > no fields within the struct) here in rte_crypto.h, but the
> > > > compiler complained that it couldn't determine the size of the
> > > > struct, even though
> > > it's a zero length array.
> > > >
> > > > That is why I had to use the uint8_t in 'uint8_t security[0];' - I
> > > > don't like this, but I couldn't find another way that kept the
> > > > compiler happy
> > > and didn't create a circular dependency.
> > >
> > > I see... would it be an option to name this struct 'struct
> > > rte_sym_docsis_op and and move actual definition inside
> > > lib/librte_cryptodev/rte_crypto_sym.h?
> > >
> > [DC] It's certainly an option and would work but I don't think it's a
> > good idea to be putting protocol specific structs like this in rte_cryptodev -
> that's what rte_security is for.
> > Do you think it would be ok to do this?
> 
> I personally don't see a problem with this.
> In fact, as an extra  thought - why we can't have docsis xform defined in
> lib/librte_cryptodev/rte_crypto_sym.h too, and then just have it  as a
> member inside struct rte_crypto_sym_xform union?
> Then we can have rte_cryptodev_sym_session that supports docsis stuff.
> 
[DC] Because DOCSIS protocol and CRC are not specifically crypto related is why
we initially went down the rawdev/multi-fn route and now the rte_security route.
I think adding docsis xforms/ops and CRC related data to cryptodev would be adding
too much non-crypto algorithm related stuff to this library. There would then be some
protocols like IPSec and PDCP with their definitions in rte_security and others like
DOCSIS in rte_cryptodev - that doesn't seem good to me.

Yes, from a DOCSIS equipment vendors point-of-view, who already use cryptodev
for just encryption/decryption, adding DOCSIS to cryptodev would be best
for them in order to get better DOCSIS support in DPDK as it would mean less
churn for their applications. However, from a DPDK point-of-view, I don't think it
would be correct to do this.

That's just my opinion, and again I'd be interested to hear other people's thoughts.

> >
> > I'd be interested to hear what cryptodev/security maintainers and others
> think too.
> > Akhil/Declan - any thoughts on best approach here?


  reply	other threads:[~2020-06-11 14:01 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-10 14:27 [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing David Coyle
2020-04-10 14:27 ` [dpdk-dev] [PATCH v3 1/4] raw/common: add multi-function interface David Coyle
2020-04-10 14:27 ` [dpdk-dev] [PATCH v3 2/4] raw/aesni_mb_mfn: add aesni_mb_mfn raw device PMD David Coyle
2020-04-10 14:27 ` [dpdk-dev] [PATCH v3 3/4] test/rawdev: add aesni_mb_mfn raw device tests David Coyle
2020-04-10 14:27 ` [dpdk-dev] [PATCH v3 4/4] doc: update docs for aesni_mb_mfn raw device PMD David Coyle
2020-04-10 22:55 ` [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing Thomas Monjalon
2020-04-14 10:21   ` Ferruh Yigit
2020-04-14 10:32     ` Thomas Monjalon
2020-04-14 13:04       ` Trahe, Fiona
2020-04-14 13:24         ` Thomas Monjalon
2020-04-14 14:02           ` Trahe, Fiona
2020-04-14 14:44             ` Thomas Monjalon
2020-04-15 22:19               ` Doherty, Declan
2020-04-15 22:33                 ` Thomas Monjalon
2020-04-21 16:46                   ` Doherty, Declan
2020-04-21 17:23                     ` Coyle, David
2020-04-22 10:51                       ` Akhil Goyal
2020-04-22 13:17                         ` Coyle, David
2020-04-22 13:44                           ` Akhil Goyal
2020-04-22 14:21                             ` Coyle, David
2020-05-01 13:18                             ` Zhang, Roy Fan
2020-05-12 17:32                               ` Coyle, David
2020-04-22 14:01                       ` Kevin Traynor
2020-04-22 14:41                         ` Coyle, David
2020-04-21 17:25                     ` Thomas Monjalon
2020-04-21 18:37                       ` Coyle, David
2020-04-21 21:51                         ` Thomas Monjalon
2020-06-04 15:13 ` [dpdk-dev] [PATCH 0/3] add support for DOCSIS protocol to security library David Coyle
2020-06-04 15:13   ` [dpdk-dev] [PATCH 1/3] security: add support for DOCSIS protocol David Coyle
2020-06-04 15:13   ` [dpdk-dev] [PATCH 2/3] cryptodev: add security operation to crypto operation David Coyle
2020-06-09 13:23     ` Ananyev, Konstantin
2020-06-09 13:50       ` Coyle, David
2020-06-10 10:40         ` Ananyev, Konstantin
2020-06-10 12:02           ` Coyle, David
2020-06-11 12:21             ` Ananyev, Konstantin
2020-06-11 14:01               ` Coyle, David [this message]
2020-06-23 18:38               ` Akhil Goyal
2020-06-24 14:11                 ` Coyle, David
2020-06-04 15:13   ` [dpdk-dev] [PATCH 3/3] crypto/aesni_mb: add support for DOCSIS protocol David Coyle
2020-06-23 10:14   ` [dpdk-dev] [PATCH v2 0/6] " David Coyle
2020-06-23 10:14     ` [dpdk-dev] [PATCH v2 1/6] cryptodev: add security operation to crypto operation David Coyle
2020-06-23 10:14     ` [dpdk-dev] [PATCH v2 2/6] security: add support for DOCSIS protocol David Coyle
2020-06-23 17:29       ` De Lara Guarch, Pablo
2020-06-26 15:15         ` Coyle, David
2020-06-23 18:06       ` Akhil Goyal
2020-06-24 14:25         ` Coyle, David
2020-06-23 10:14     ` [dpdk-dev] [PATCH v2 3/6] crypto/aesni_mb: " David Coyle
2020-06-23 17:57       ` De Lara Guarch, Pablo
2020-06-26 15:13         ` Coyle, David
2020-06-23 10:14     ` [dpdk-dev] [PATCH v2 4/6] crypto/qat: " David Coyle
2020-06-23 10:14     ` [dpdk-dev] [PATCH v2 5/6] test/crypto: add DOCSIS security test cases David Coyle
2020-06-23 18:04       ` De Lara Guarch, Pablo
2020-06-26 15:14         ` Coyle, David
2020-06-23 10:14     ` [dpdk-dev] [PATCH v2 6/6] test/security: add DOCSIS capability check tests David Coyle
2020-06-23 14:51     ` [dpdk-dev] [PATCH v2 0/6] add support for DOCSIS protocol David Marchand
2020-06-23 15:18       ` Coyle, David
2020-06-23 15:38         ` David Marchand
2020-06-23 15:56           ` Coyle, David
2020-06-23 16:22             ` David Marchand
2020-06-23 16:27               ` Coyle, David
2020-06-30 16:30     ` [dpdk-dev] [PATCH v3 0/8] " David Coyle
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 1/8] security: " David Coyle
2020-07-01 21:41         ` Akhil Goyal
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 2/8] cryptodev: add a note regarding DOCSIS protocol support David Coyle
2020-07-01 21:42         ` Akhil Goyal
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 3/8] crypto/aesni_mb: add support for DOCSIS protocol David Coyle
2020-07-01 17:04         ` Coyle, David
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 4/8] crypto/qat: " David Coyle
2020-07-01 17:04         ` Coyle, David
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 5/8] test/crypto: add DOCSIS security test cases David Coyle
2020-07-01 21:43         ` Akhil Goyal
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 6/8] test/security: add DOCSIS capability check tests David Coyle
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 7/8] app/crypto-perf: add support for DOCSIS protocol David Coyle
2020-07-01 21:44         ` Akhil Goyal
2020-06-30 16:30       ` [dpdk-dev] [PATCH v3 8/8] doc: add doc updates for DOCSIS security protocol David Coyle
2020-06-30 18:33         ` Akhil Goyal
2020-07-01 17:03           ` Coyle, David
2020-07-03 12:39       ` [dpdk-dev] [PATCH v4 0/7] add support for DOCSIS protocol David Coyle
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 1/7] security: " David Coyle
2020-07-03 17:50           ` De Lara Guarch, Pablo
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 2/7] cryptodev: add a note regarding DOCSIS protocol support David Coyle
2020-07-03 17:56           ` De Lara Guarch, Pablo
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 3/7] crypto/aesni_mb: add support for DOCSIS protocol David Coyle
2020-07-03 17:56           ` De Lara Guarch, Pablo
2020-07-04 19:55           ` Akhil Goyal
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 4/7] crypto/qat: " David Coyle
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 5/7] test/crypto: add DOCSIS security test cases David Coyle
2020-07-03 17:56           ` De Lara Guarch, Pablo
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 6/7] test/security: add DOCSIS capability check tests David Coyle
2020-07-03 12:39         ` [dpdk-dev] [PATCH v4 7/7] app/crypto-perf: add support for DOCSIS protocol David Coyle
2020-07-03 17:57           ` De Lara Guarch, Pablo
2020-07-04 19:54         ` [dpdk-dev] [PATCH v4 0/7] " Akhil Goyal

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=MN2PR11MB3550B4F23C2D162CA0DA68DEE3800@MN2PR11MB3550.namprd11.prod.outlook.com \
    --to=david.coyle@intel.com \
    --cc=G.Singh@nxp.com \
    --cc=akhil.goyal@nxp.com \
    --cc=alexr@mellanox.com \
    --cc=anoobj@marvell.com \
    --cc=brendan.ryan@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=fiona.trahe@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=jsrikanth@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=lironh@marvell.com \
    --cc=mairtin.oloingsigh@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=ravi1.kumar@amd.com \
    --cc=rnagadheeraj@marvell.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=ruifeng.wang@arm.com \
    --cc=stephen@networkplumber.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).