DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: "Coyle, David" <david.coyle@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>
Cc: "techboard@dpdk.org" <techboard@dpdk.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	 "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"Ryan, Brendan" <brendan.ryan@intel.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Anoob Joseph <anoobj@marvell.com>,
	Ruifeng Wang <ruifeng.wang@arm.com>,
	Liron Himi <lironh@marvell.com>,
	Nagadheeraj Rottela <rnagadheeraj@marvell.com>,
	Srikanth Jampala <jsrikanth@marvell.com>,
	Gagandeep Singh <G.Singh@nxp.com>,
	Jay Zhou <jianjay.zhou@huawei.com>,
	Ravi Kumar <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 Hemminger <stephen@networkplumber.org>,
	"alexr@mellanox.com" <alexr@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing
Date: Wed, 22 Apr 2020 13:44:01 +0000	[thread overview]
Message-ID: <VI1PR04MB3168DCC247E1F77A498DAEBCE6D20@VI1PR04MB3168.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <MN2PR11MB3550F012DE6FDB39AFFCCE59E3D20@MN2PR11MB3550.namprd11.prod.outlook.com>

Hi David,
> Hi Akhil,
> 
> > -----Original Message-----
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > Sent: Wednesday, April 22, 2020 11:51 AM
> > Hi David,
> > > > >>
> > > > >> I don't agree rte_security addresses the problem of different
> > > > >> device types supporting the same services. The problem being
> > > > >> addressed here is a single device which supports the chaining of
> > > > >> multiple services (sym crypto & error detection)
> > > > >
> > > > > Doing IPsec processing in Rx or Tx of a NIC is not chaining?
> > > > >
> > > > I wouldn't consider an inline crypto offload or full IPsec offload a
> > > > chained operation in the vein being proposed here where completely
> > > > independent services (in the view of DPDK which are currently on
> > > > independent devices and APIs) are linked together.
> > > >
> > > > We did look at using rte_security here but it wasn't considered
> > > > suitable for a chaining of non-crypto operations such as CRC or
> > > > possibly compression in the future, as it would still run into the
> > > > issue of having to use the cryptodev enq/deq API in the lookaside offload
> > case.
> > > >
> > > >
> > I did not look at your patches completely, but looking at the ops that you
> > have added For rawdev are pretty much same as that of a crypto device.
> >
> > I see that there are 2 types of ops that you need
> > - session create/destroy
> > - enq/deq
> >
> > On the first impression of your patchset, I see that you want to enq to driver
> > only once for both The operations - CRC and crypto.
> >
> > So what is the issue in using the cryptodev_enqueue for processing in the
> > existing AESNI-MB driver.
> > For session creation, the cryptodev layer will not give flexibility to add
> > CRC+crypto kind of sessions.
> > But in case of rte_security, you can define your new session xform based on
> > your requirement.
> >
> > And while doing the cryptodev enq/deq, based on the session type, you can
> > process the packet Specific to your usecase in your aesni-mb PMD
> >
> > Now if you want to add compression also along with crypto, then you can
> > define another xform which Will be combination of crypto+compression and
> > the aesni-mb PMD can have another mode which Can make sessions based
> > on the new xform and the enq and deq can be done using the cryptodev
> > enq/deq.
> > For all your cases you will be having only one action type - lookaside protocol
> > and can define different Protocols (that may not be standard).
> >
> > So to conclude, your AESNI-MB will have 3 types of operations
> > - plain crypto
> > - crc+crypto
> > - compression+crypto
> >
> > I believe this is doable or did I miss something very obvious?
> 
> [DC] Thank you for this feedback
> 
> I have done this exact same analysis on rte_security and how we could use it.
> 
> The main issue of this approach (and it may be possible to easily overcome) is
> that ultimately crypto_op's need
> to be enqueued into cryptodev. This means we can't easily control the CRC (or
> compression in the future) at the
> operation level - application developers using this API would create a
> Crypto+CRC security xform session  for a
> particular flow but may want to turn off the CRC part for some packets in that
> flow.
> 
> There are a number of ways this issue could possibly be overcome:
> 1) the auth offset/length fields in a rte_crypto_op could be overloaded to
> control the CRC part of the combined operation
>     - this is not the cleanest approach
> 2) we add a "security" op struct of some type to the union at end of the
> rte_crypto_op
>     - to avoid any circular dependencies, this would need to be opaque to
> rte_cryptodev
>     - rte_cryptodev should not be aware of rte_security
> 
> Number 2 above is probably the cleaner and more preferable approach.

Yes, it is preferred, but it should be a union to rte_crypto_sym_op/rte_crypto_asym_op.
Crypto_op->type as RTE_CRYPTO_OP_TYPE_SECURITY and sess_type as
RTE_CRYPTO_OP_SECURITY_SESSION
The size of rte_crypto_op will remain as is and there will be no ABI breakage I guess.

One more thing that can be looked into is the recently added CPU crypto process API
If that could of any use, we may extend that if need be.

> 
> The other approach is that CRC is either on/off at the session level. That
> limitation would then need to be adhered
> by application developers, which is something we would ideally like to avoid.

You mean that CRC can be on/off per session as well as per packet?
I think that can also be handled when you are defining your own security_op for per packet.

> 
> The rawdev multi-function approach did not have these issues which is one of
> the reasons we have pursued this
> approach to date.
> 
> However, we think the rte_security approach is workable.
> It still requires some deeper analysis but with your support, we think we can
> overcome the challenges.
> 
Yes, please let me know where ever my help is required.

  reply	other threads:[~2020-04-22 13:44 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-10 14:27 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 [this message]
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
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=VI1PR04MB3168DCC247E1F77A498DAEBCE6D20@VI1PR04MB3168.eurprd04.prod.outlook.com \
    --to=akhil.goyal@nxp.com \
    --cc=G.Singh@nxp.com \
    --cc=alexr@mellanox.com \
    --cc=anoobj@marvell.com \
    --cc=brendan.ryan@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.coyle@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=jianjay.zhou@huawei.com \
    --cc=jsrikanth@marvell.com \
    --cc=lironh@marvell.com \
    --cc=olivier.matz@6wind.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=ravi1.kumar@amd.com \
    --cc=rnagadheeraj@marvell.com \
    --cc=ruifeng.wang@arm.com \
    --cc=stephen@networkplumber.org \
    --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).