From: "Coyle, David" <david.coyle@intel.com>
To: "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>,
"shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"akhil.goyal@nxp.com" <akhil.goyal@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: Tue, 21 Apr 2020 17:23:02 +0000 [thread overview]
Message-ID: <MN2PR11MB3550E8BF5E2662924C646DDFE3D50@MN2PR11MB3550.namprd11.prod.outlook.com> (raw)
In-Reply-To: <45cf0e87-2021-cc8c-82b5-60c0b1e11fb7@intel.com>
Thank you Thomas for your input.
We would like to request that the Tech-Board (CC'ed) also review the proposal to help us reach a consensus.
If the current proposal is not acceptable, we would welcome feedback from the board on how to rework our
proposal to something that would be acceptable.
For the benefit of the Tech-Board here is the back-ground to our proposal for Rawdev-based multi-function
processing:
- The primary objective is to support the AESNI MB combined Crypto-CRC processing capability in DPDK and
in future to add support for combined Crypto-CRC support in QAT.
- The cryptodev API was considered unsuitable because CRC is not a cryptographic operation, and this would
also preclude other non-crypto operations in the future such as compression.
- The rte_security API was also not considered suitable for chaining of non-crypto operations such as CRC,
as Declan pointed out below.
- A new Accelerator API was proposed as an RFC but was not pursued due to community feedback that a
new API would not be welcome for a single use-case.
- Using Rawdev for multi-function processing was then proposed and, initially, as there was no opposition
we implemented a patch-set for this approach.
It was considered that a Rawdev-based multi-function approach would be suitable for the following reasons:
1) Multi-function processing for Crypto-CRC cases is not a good fit for any of the existing DPDK classes.
2) Rawdev was intended for such specialized acceleration processing that are not a good fit for existing DPDK
classes.
3) Rawdev was also intended as somewhere that new use-cases like this could be prototyped and developed,
such as Declan mentions below
4) The Rawdev-based multi-function proposal is extensible and we would hope that it can evolve to support
new use-cases and target new devices in the future with the communities involvement.
> -----Original Message-----
> From: Doherty, Declan <declan.doherty@intel.com>
> Sent: Tuesday, April 21, 2020 5:46 PM
>
> On 15/04/2020 11:33 PM, Thomas Monjalon wrote:
> > 16/04/2020 00:19, Doherty, Declan:
> >> On 14/04/2020 3:44 PM, Thomas Monjalon wrote:
> >>> 14/04/2020 16:02, Trahe, Fiona:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> 14/04/2020 15:04, Trahe, Fiona:
> >>>>>>> 14/04/2020 12:21, Ferruh Yigit:
> >>>>>>>
> >>>>>
> http://inbox.dpdk.org/dev/MN2PR11MB35507D4B96677A41E66440C5E3C30
> @M
> >>>>> N2PR11MB3550.na
> >>>>>>> mprd11.prod.outlook.com/
> >>>>>>>
> >>>>>>> I am not convinced.
> >>>>>>> I don't like rawdev in general.
> >>>>>>> Rawdev is good only for hardware support which cannot be generic
> >>>>>>> like SoC, FPGA management or DMA engine.
> >>>>>>
> >>>>>> [Fiona] CRC and BIP are not crypto algorithms, they are error
> detection processes.
> >>>>>> So there is no class in DPDK that these readily fit into.
> >>>>>> There was resistance to adding another xxxddev, and even if one
> >>>>>> had been added for error_detection_dev, there would still have
> >>>>>> been another layer needed to couple this with cryptodev. Various
> >>>>>> proposals for this have been discussed on the ML in RFC and recent
> patches, there doesn't seem to be an appetite for this as a generic API.
> >>>>>> So it seems that only Intel has software and hardware engines
> >>>>>> that provide this specialised feature coupling. In that case
> >>>>>> rawdev seems like the most appropriate vehicle to expose this.
> >>>>>
> >>>>> Adding some vendor-specific API is not a good answer.
> >>>>> It will work in some cases, but it won't make DPDK better.
> >>>>> What's the purpose of DPDK if it's not solving a common problem
> >>>>> for different hardware?
> >>>>
> >> The current proposal in rawdev could easily be supported by any
> >> hardware which supports chaining multiple functions/services into a
> >> single operation, in this case symmetric crypto and error detection,
> >> but it could conceivably support chaining symmetric/asymmetric crypto
> >> operations or chaining symmetric crypto and compression operations.
> >>
> >>>> [Fiona] Based on that logic rawdev should be deprecated.
> >>>> But the community has agreed that it has a place.
> >>>
> >>> No, as I said above, rawdev is good for SoC, FPGA management or DMA
> engine.
> >>
> >> I distinctly remember when rawdev was being proposed one of the uses
> >> cases proposed was that a new classes of APIs could be prototyped and
> >> developed under rawdev and when a solid consensus was reached then
> >> migrated to a mainstream DPDK library. I think every effort has been
> >> made here to engage the community to develop a generic approach. As
> >> Fiona notes there hasn't really been much of an appetite for this.
> >>
> >> Therefore I think the option to use rawdev makes sense, it allows an
> >> initial proposal to be deployed, without a generic solution
> >> agreement, it will also give others in the community to see how this
> >> approach can work and hopefully lead to more engagement on a generic
> >> solution. Also as APIs in rawdev are essentially treated as private
> >> APIs the onus is on Intel to support this going forward.
> >
> > Because hardware support is pending,
> > we should accept an Intel-only "temporary" solution, opening the door
> > to more vendor-specific APIs?
> >
> > What is the benefit for the DPDK project?
> >
> Sorry I don't agree with this sentiment, David has made every attempt to
> solicit feedback and to engage the community in this.
>
> I also don't agree in classifying this as a "temporary solution" as this is a solid
> proposal for an approach to chaining multiple operations together, but I
> guess the fact remains that we only currently have a single use-case, but it is
> difficult to generate a generic solution in this case.
>
> While there is only a single use case it is targeting two devices so that drove
> the need for a common interface within rawdev.
>
> The advantage of using rawdev is that it allows this to be consumed through
> DPDK, which enables DPDK project consumers, but also leaves the door open
> to other contributors to have their say on how this should evolve. For
> example this exact process seems to be occurring with DMA engines in
> rawdev today, with a critical mass of implementations which now is giving the
> impetus to create a generic solution, as we would hope can occur here too in
> the future.
>
>
> >>>> And the common problem here is device exposure.
> >>>> With a specialised service on top.
> >>>>
> >>>>
> >>>>>>> Here the intent is to use rawdev because we don't find a good API.
> >>>>>>> API defeat is a no-go.
> >>>>>>
> >>>>>> [Fiona] It's not that we haven't found a good API, but that there
> >>>>>> doesn't seem to be a general requirement for such a specialised
> >>>>>> API
> >>>>>
> >>>>> There is a requirement to combine features of different classes.
> >>>>
> >>>> [Fiona] Can you point me to that requirement please?
> >>>
> >>> Yes, rte_security is trying to address this exact issue.
> >>>
> >>
> >> 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.
>
>
> >>>> We suggested it, but did not get community engagement and have
> >>>> dropped our generic API requirement, instead focussing on this
> specialised case.
> >>>
> >>> I did not see such generic proposal, sorry.
> >>>
> >>>>> In the past, rte_security was an "answer" to this issue with crypto and
> ethdev.
> >>>>> This is a real topic, please let's find a generic elegant solution.
> >
> >
> >
next prev parent reply other threads:[~2020-04-21 17:23 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 [this message]
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
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=MN2PR11MB3550E8BF5E2662924C646DDFE3D50@MN2PR11MB3550.namprd11.prod.outlook.com \
--to=david.coyle@intel.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=g.singh@nxp.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=shreyansh.jain@nxp.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).