Hi Akhil, > > This action type allows the burst of symmetric crypto workload using the > > same > > algorithm, key, and direction being processed by CPU cycles synchronously. > > This flexible action type does not require external hardware involvement, > > having the crypto workload processed synchronously, and is more performant > > than Cryptodev SW PMD due to the saved cycles on removed "async mode > > simulation" as well as 3 cacheline access of the crypto ops. > > Does that mean application will not call the cryptodev_enqueue_burst and > corresponding dequeue burst.
Yes, instead it just call rte_security_process_cpu_crypto_bulk(...) > It would be a new API something like process_packets and it will have the > crypto processed packets while returning from the API? Yes, though the plan is that API will operate on raw data buffers, not mbufs. > > I still do not understand why we cannot do with the conventional crypto lib > only. > As far as I can understand, you are not doing any protocol processing or any > value add > To the crypto processing. IMO, you just need a synchronous crypto processing > API which > Can be defined in cryptodev, you don't need to re-create a crypto session in > the name of > Security session in the driver just to do a synchronous processing. I suppose your question is why not to have rte_crypot_process_cpu_crypto_bulk(...) instead? The main reason is that would require disruptive changes in existing cryptodev API (would cause ABI/API breakage). Session for RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO need some extra information that normal crypto_sym_xform doesn't contain (cipher offset from the start of the buffer, might be something extra in future). Also right now there is no way to add new type of crypto_sym_session without either breaking existing crypto-dev ABI/API or introducing new structure (rte_crypto_sym_cpu_session or so) for that. While rte_security is designed in a way that we can add new session types and related parameters without causing API/ABI breakage. BTW, what is your concern with proposed approach (via rte_security)? >From my perspective it is a lightweight change and it is totally optional for the crypto PMDs to support it or not. Konstantin > > > > AESNI-GCM and AESNI-MB PMDs are updated with this support. There is a small > > performance test app under app/test/security_aesni_gcm(mb)_perftest to > > prove. > > > > For the new API > > The packet is sent to the crypto device for symmetric crypto > > processing. The device will encrypt or decrypt the buffer based on the > > session > > data specified and preprocessed in the security session. Different > > than the inline or lookaside modes, when the function exits, the user will > > expect the buffers are either processed successfully, or having the error > > number > > assigned to the appropriate index of the status array. > > > > Will update the program's guide in the v1 patch. > > > > Regards, > > Fan > > > > > -----Original Message----- > > > From: Akhil Goyal [mailto:akhil.go...@nxp.com] > > > Sent: Wednesday, September 4, 2019 11:33 AM > > > To: Zhang, Roy Fan <roy.fan.zh...@intel.com>; dev@dpdk.org > > > Cc: Ananyev, Konstantin <konstantin.anan...@intel.com>; Doherty, Declan > > > <declan.dohe...@intel.com>; De Lara Guarch, Pablo > > > <pablo.de.lara.gua...@intel.com> > > > Subject: RE: [RFC PATCH 1/9] security: introduce CPU Crypto action type > > > and > > > API > > > > > > Hi Fan, > > > > > > > > > > > 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. > > > > > > > I am not able to get the flow of execution for this action type. Could you > > > please elaborate the flow in the documentation. If not in documentation > > > right now, then please elaborate the flow in cover letter. > > > Also I see that there are new APIs for processing crypto operations in > > > bulk. > > > What does that mean. How are they different from the existing APIs which > > > are also handling bulk crypto ops depending on the budget. > > > > > > > > > -Akhil
