Hi,

I am working on moving odp-dpdk from dpdk 17.02 to 17.08. But due to
updates in dpdk crypto which are not backward compatible, makes it
difficult to implement changes in odp-dpdk. One major update is moving
"AES_GCM & AES_CCM" algorithms to a separate enum called
"rte_crypto_aead_algorithm". This means dpdk now has three enums  auth,
cipher & aead. They each have separate crypto_xforms in terms of getting
capability params & their validation. From ODP crypto api perspective,
AES_GCM & AES_CCM are still part of both cipher_alogos & auth_algos.
Complexity arises when application asks for,

- capability for cipher & auth, implementation first needs to convert
cipher_algos to rte_cipher_algo or rte_aead_algo and set the cipher_xform
or aead_xform before asking dpdk for capability and map those capabilities
to odp_crypto_cipher_capability_t array. Same goes with Auth_algo. This
makes the implementation logic be unreadable.

- In 17.08 dpdk also supports cipher only, auth only. So when mixing this
feature with algos conversion also introduces complexity.

- getting the device based on cipher, auth, aead algos. In 17.08 dpdk
facilitates api's for respective crypto_xform for capability verification.
Currently when application wants to create a session, implementations
fetches the device that suits to the params sent in odp_session_params. So
when try to cross verify the params with corresponding crypto algo,
Implementation again does the conversion and set the right transform and
probe the corresponding crypto api.

I am starting this thread to see if it would be feasible to change the
crypto api in order to make the odp & implementation be more compatible
with dpdk and make use of all the new api's that were introduced in the
newer dpdk versions.

/Krishna

Reply via email to