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