Message ID | 20200924163417.49983-1-roy.fan.zhang@intel.com |
---|---|
Headers | show |
Series |
|
Related | show |
Hi Fan, > The Crypto Raw data-path APIs are a set of APIs are designed to enable > externel libraries/applications which want to leverage the cryptographic > processing provided by DPDK crypto PMDs through the cryptodev API but in a > manner that is not dependent on native DPDK data structures (eg. rte_mbuf, > rte_crypto_op, ... etc) in their data-path implementation. > > The raw data-path APIs have the following advantages: > - External data structure friendly design. The new APIs uses the operation > descriptor ``struct rte_crypto_sym_vec`` that supports raw data pointer and > IOVA addresses as input. Moreover, the APIs does not require the user to > allocate the descriptor from mempool, nor requiring mbufs to describe input > data's virtual and IOVA addresses. All these features made the translation > from user's own data structure into the descriptor easier and more efficient. > - Flexible enqueue and dequeue operation. The raw data-path APIs gives the > user more control to the enqueue and dequeue operations, including the > capability of precious enqueue/dequeue count, abandoning enqueue or dequeue > at any time, and operation status translation and set on the fly. > > V10: > - Changed rte_crypto_sym_vec structure to support both sync cpu_crypto and > async raw data-path API. > - Changed documentation. > - Changed API names. > - Changed the way data-path context is initialized. > - Added new API to attach session or xform to existing context. > - Changed QAT PMD accordingly with new APIs. > - Changed unit test to use the device feature flag for the raw API tests. > I have some comment on the V10, please revert asap so that these can be merged in RC1. @konstantin.ananyev@intel.com: Could you please have a look at the 2/4 patch as well? Regards, Akhil
Ok. Will do ASAP. > -----Original Message----- > From: Akhil Goyal <akhil.goyal@nxp.com> > Sent: Thursday, October 8, 2020 4:04 PM > To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org; Ananyev, > Konstantin <konstantin.ananyev@intel.com> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; Kusztal, ArkadiuszX > <arkadiuszx.kusztal@intel.com>; Dybkowski, AdamX > <adamx.dybkowski@intel.com>; anoobj@marvell.com > Subject: RE: [dpdk-dev v10 0/4] cryptodev: add raw data-path APIs > > Hi Fan, > > > The Crypto Raw data-path APIs are a set of APIs are designed to enable > > externel libraries/applications which want to leverage the cryptographic > > processing provided by DPDK crypto PMDs through the cryptodev API but > in a > > manner that is not dependent on native DPDK data structures (eg. > rte_mbuf, > > rte_crypto_op, ... etc) in their data-path implementation. > > > > The raw data-path APIs have the following advantages: > > - External data structure friendly design. The new APIs uses the operation > > descriptor ``struct rte_crypto_sym_vec`` that supports raw data pointer > and > > IOVA addresses as input. Moreover, the APIs does not require the user to > > allocate the descriptor from mempool, nor requiring mbufs to describe > input > > data's virtual and IOVA addresses. All these features made the translation > > from user's own data structure into the descriptor easier and more > efficient. > > - Flexible enqueue and dequeue operation. The raw data-path APIs gives > the > > user more control to the enqueue and dequeue operations, including the > > capability of precious enqueue/dequeue count, abandoning enqueue or > dequeue > > at any time, and operation status translation and set on the fly. > > > > V10: > > - Changed rte_crypto_sym_vec structure to support both sync cpu_crypto > and > > async raw data-path API. > > - Changed documentation. > > - Changed API names. > > - Changed the way data-path context is initialized. > > - Added new API to attach session or xform to existing context. > > - Changed QAT PMD accordingly with new APIs. > > - Changed unit test to use the device feature flag for the raw API tests. > > > I have some comment on the V10, please revert asap so that these can be > merged in RC1. > > @konstantin.ananyev@intel.com: Could you please have a look at the 2/4 > patch as well? > > Regards, > Akhil