Hi Konstantin, > > >>> This patch introduce new RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > > >>> action type to security library. The type represents performing > > >>> crypto operation with CPU cycles. The patch also includes a new > > >>> API to process crypto operations in bulk and the function pointers for > PMDs. > > >>> > > >>> Signed-off-by: Fan Zhang <roy.fan.zh...@intel.com> > > >>> --- > > >>> lib/librte_security/rte_security.c | 16 +++++++++ > > >>> lib/librte_security/rte_security.h | 51 > +++++++++++++++++++++++++++- > > >>> lib/librte_security/rte_security_driver.h | 19 +++++++++++ > > >>> lib/librte_security/rte_security_version.map | 1 + > > >>> 4 files changed, 86 insertions(+), 1 deletion(-) > > >>> > > >>> diff --git a/lib/librte_security/rte_security.c > > >>> b/lib/librte_security/rte_security.c > > >>> index bc81ce15d..0f85c1b59 100644 > > >>> --- a/lib/librte_security/rte_security.c > > >>> +++ b/lib/librte_security/rte_security.c > > >>> @@ -141,3 +141,19 @@ rte_security_capability_get(struct > > >>> rte_security_ctx *instance, > > >>> > > >>> return NULL; > > >>> } > > >>> + > > >>> +void > > >>> +rte_security_process_cpu_crypto_bulk(struct rte_security_ctx > *instance, > > >>> + struct rte_security_session *sess, > > >>> + struct rte_security_vec buf[], void *iv[], void *aad[], > > >>> + void *digest[], int status[], uint32_t num) { > > >>> + uint32_t i; > > >>> + > > >>> + for (i = 0; i < num; i++) > > >>> + status[i] = -1; > > >>> + > > >>> + RTE_FUNC_PTR_OR_RET(*instance->ops->process_cpu_crypto_bulk); > > >>> + instance->ops->process_cpu_crypto_bulk(sess, buf, iv, > > >>> + aad, digest, status, num); > > >>> +} > > >>> diff --git a/lib/librte_security/rte_security.h > > >>> b/lib/librte_security/rte_security.h > > >>> index 96806e3a2..5a0f8901b 100644 > > >>> --- a/lib/librte_security/rte_security.h > > >>> +++ b/lib/librte_security/rte_security.h > > >>> @@ -18,6 +18,7 @@ extern "C" { > > >>> #endif > > >>> > > >>> #include <sys/types.h> > > >>> +#include <sys/uio.h> > > >>> > > >>> #include <netinet/in.h> > > >>> #include <netinet/ip.h> > > >>> @@ -272,6 +273,20 @@ struct rte_security_pdcp_xform { > > >>> uint32_t hfn_threshold; > > >>> }; > > >>> > > >>> +struct rte_security_cpu_crypto_xform { > > >>> + /** For cipher/authentication crypto operation the > > >>> authentication > may > > >>> + * cover more content then the cipher. E.g., for IPSec ESP > > >>> encryption > > >>> + * with AES-CBC and SHA1-HMAC, the encryption happens after the > ESP > > >>> + * header but whole packet (apart from MAC header) is > authenticated. > > >>> + * The cipher_offset field is used to deduct the cipher data > > >>> pointer > > >>> + * from the buffer to be processed. > > >>> + * > > >>> + * NOTE this parameter shall be ignored by AEAD algorithms, > > >>> since it > > >>> + * uses the same offset for cipher and authentication. > > >>> + */ > > >>> + int32_t cipher_offset; > > >>> +}; > > >>> + > > >>> /** > > >>> * Security session action type. > > >>> */ > > >>> @@ -286,10 +301,14 @@ enum rte_security_session_action_type { > > >>> /**< All security protocol processing is performed inline during > > >>> * transmission > > >>> */ > > >>> - RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL > > >>> + RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, > > >>> /**< All security protocol processing including crypto is > > >>> performed > > >>> * on a lookaside accelerator > > >>> */ > > >>> + RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > > >>> + /**< Crypto processing for security protocol is processed by CPU > > >>> + * synchronously > > >>> + */ > > >> though you are naming it cpu crypto, but it is more like raw packet > > >> crypto, where you want to skip mbuf/crypto ops and directly wants > > >> to work on raw buffer. > > > Yes, but we do wat to do that (skip mbuf/crypto ops and use raw > > > buffer), because this API is destined for SW backed implementation. > > > For that case crypto-ops , mbuf, enqueue/dequeue are just unnecessary > overhead. > > I agree, we are also planning to take advantage of it for some > > specific use-cases in future. > > >>> }; > > >>> > > >>> /** Security session protocol definition */ @@ -315,6 +334,7 @@ > > >>> struct rte_security_session_conf { > > >>> struct rte_security_ipsec_xform ipsec; > > >>> struct rte_security_macsec_xform macsec; > > >>> struct rte_security_pdcp_xform pdcp; > > >>> + struct rte_security_cpu_crypto_xform cpucrypto; > > >>> }; > > >>> /**< Configuration parameters for security session */ > > >>> struct rte_crypto_sym_xform *crypto_xform; @@ -639,6 +659,35 > > >>> @@ const struct rte_security_capability * > > >>> rte_security_capability_get(struct rte_security_ctx *instance, > > >>> struct rte_security_capability_idx *idx); > > >>> > > >>> +/** > > >>> + * Security vector structure, contains pointer to vector array > > >>> +and the length > > >>> + * of the array > > >>> + */ > > >>> +struct rte_security_vec { > > >>> + struct iovec *vec; > > >>> + uint32_t num; > > >>> +}; > > >>> + > > >> Just wondering if you want to change it to *in_vec and *out_vec, > > >> that will be helpful in future, if the out-of-place processing is > > >> required for CPU usecase as well? > > > I suppose this is doable, though right now we don't plan to support such > model. > > They will come handy in future. I plan to use it in future and we can > > skip the API/ABI breakage, if the placeholder are present > > > > > >>> +/** > > >>> + * Processing bulk crypto workload with CPU > > >>> + * > > >>> + * @param instance security instance. > > >>> + * @param sess security session > > >>> + * @param buf array of buffer SGL vectors > > >>> + * @param iv array of IV pointers > > >>> + * @param aad array of AAD pointers > > >>> + * @param digest array of digest pointers > > >>> + * @param status array of status for the function to > return > > >>> + * @param num number of elements in each array > > >>> + * > > >>> + */ > > >>> +__rte_experimental > > >>> +void > > >>> +rte_security_process_cpu_crypto_bulk(struct rte_security_ctx > *instance, > > >>> + struct rte_security_session *sess, > > >>> + struct rte_security_vec buf[], void *iv[], void *aad[], > > >>> + void *digest[], int status[], uint32_t num); > > >>> + > > >> Why not make the return as int, to indicate whether this API > > >> completely failed or processed or have some valid status to look into? > > > Good point, will change as suggested. > > > > I have another suggestions w.r.t iv, aad, digest etc. Why not put them > > in a structure, so that you will > > > > be able to add/remove the variable without breaking the API prototype. > > > Just to confirm, you are talking about something like: > > struct rte_security_vec { > struct iovec *vec; > uint32_t num; > };
[Hemant] My idea is: struct rte_security_vec { struct iovec *vec; struct iovec *out_vec; uint32_t num_in; uint32_t num_out; }; > > struct rte_security_sym_vec { > struct rte_security_vec buf; > void *iv; > void *aad; > void *digest; > }; > [Hemant] or leave the rte_security_vec altogether and make it part of rte_security_sym_vec itself. > rte_security_process_cpu_crypto_bulk(struct rte_security_ctx *instance, > struct rte_security_session *sess, struct rte_security_sym_vec buf[], > int status[], uint32_t num); > > ? > We thought about such way, though for PMD it would be more plausible to > have same type of params grouped together, i.e. void *in[], void *out[], void > *digest[], ... > Another thing - above grouping wouldn't help to avoid ABI breakage, in case > we'll need to add new field into rte_security_sym_vec (though it might help > to avoid API breakage). > > In theory other way is also possible: > struct rte_security_sym_vec { > struct rte_security_vec *buf; > void **iv; > void **aad; > void **digest; > }; > > rte_security_process_cpu_crypto_bulk(struct rte_security_ctx *instance, > struct rte_security_session *sess, struct rte_security_sym_vec *buf, > int status[], uint32_t num); > > And that might help for both ABI and API stability, but it looks really weird > that way (at least to me). [Hemant] I am fine either way. > Also this API is experimental and I suppose needs to stay experimental for > few releases before we are sure nothing important is missing, so probably > API/ABI stability is not that high concern for it right now. > > Konstantin > >