[dpdk-dev] [RFC PATCH v2 0/4] IPSec Inline and look aside crypto offload
Narayana Prasad Athreya
pathreya at caviumnetworks.com
Mon Aug 28 16:26:05 CEST 2017
On Monday 28 August 2017 07:53 PM, Narayana Prasad Athreya wrote:
>> This patchet showcases the definition and usage of the rte_security
>> APIs described in the RFC v1 sent earlier.
>>
>> The data path and configuration path is similar to what was proposed in
>> version 1. However, rte_security_configure API is removed, as it looked
>> redundant.
>>
>> Also the rte_security.x files are placed inside the lib/librte_cryptodev/
>> as the APIs are defined with the help of crypto APIs and it makes more sense
>> to extend the cryptodev library instead of a separate library which perform
>> similar actions.
>>
>> Some of the parameters of the APIs are also modified for better usability.
>> The parameter ``dev_name`` is removed as the appropriate device(crypto/eth)
>> can be obtained by using the action type.
>>
>> The patchset is still in work in progress state and there may be some changes
>> and cleanup in the next version. This is just to enable others to work
>> in parallel on the crypto offloading using ethernet devices.
>>
>> This patchset include the definition of rte_security APIs in patch 1,
>> changes required in cryptodev in patch 2, sample driver implementation
>> in patch 3 and ipsec-secgw application changes in patch 4.
>>
>> Akhil Goyal (4):
>> RFC2: rte_security: API definitions
>> cryptodev: entend cryptodev to support security APIs
>> crypto/dpaa2_sec: add support for protocol offload ipsec
>> example/ipsec-secgw: add support for offloading crypto op
>>
>> drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 368 ++++++++++++++++++++++++-
>> drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 33 +++
>> examples/ipsec-secgw/ipsec.c | 125 ++++++---
>> examples/ipsec-secgw/ipsec.h | 13 +-
>> examples/ipsec-secgw/sa.c | 142 +++++++---
>> lib/librte_cryptodev/Makefile | 3 +-
>> lib/librte_cryptodev/rte_crypto_sym.h | 15 +
>> lib/librte_cryptodev/rte_cryptodev.h | 20 +-
>> lib/librte_cryptodev/rte_cryptodev_pmd.h | 35 +++
>> lib/librte_cryptodev/rte_security.c | 171 ++++++++++++
>> lib/librte_cryptodev/rte_security.h | 409 ++++++++++++++++++++++++++++
>> 11 files changed, 1243 insertions(+), 91 deletions(-)
>> create mode 100644 lib/librte_cryptodev/rte_security.c
>> create mode 100644 lib/librte_cryptodev/rte_security.h
>>
>> --
>> 2.9.3
> I have a few questions/comments on the v1 and v2 versions of this
> patch. I accumulated these from a few different cavium stakeholders.
>
> 1. conf_ipsec_sa::sa_dir and ipsec_xform::op seem to have same purpose.
> 2. Its unclear how the Crypto Device will be configured to use a
> specific Network device and vice-versa. The situation is when the same
> network port must process IPsec and regular traffic. Should regular
> traffic also use the singular device?
> 3. The spec seems to assume PMD Network device. Event driven model is
> also needed.
> 4. SA Options for expiry(byte/time) are lacking.
> 5. Error handling and Status notifications are not specified. These
> can be tricky in the inline mode of operation, particularly inbound.
> 6. SA expiry handling is another key aspect which hasn’t been
> accounted for.
> 7. No anti-replay window size SA param.
> 8. ESP TFC padding not addressed.
> 9. Incremental checksum computation in transport mode ESP doesnt
> appear to be addressed
> 10. Didnt spot details for tunnel mode header preservation
> 11. Selector checking, especially for the inner packet in tunnel mode
> appears to be missing
> 12. Dynamic offloading - selectively offload some packets in hardware
> is a feature we would like to support.
> 13. Destination queue for IPSEC events: Operations in asynchronous or
> inline mode enqueue resulting events into this queue. This helps with
> our 93xx inline ipsec design.
> 14. If event model (ASYNC) and inline are supported, there should be a
> “pipeline” classifier option for inbound SAs.
> 15. Maximum number of destination CoSes is not supported. The same CoS
> may be used for many SAs.
> 16. Per protocol header parsing capability after inbound processing
> is missing. Preferred options : None/L2/L3/L4/ALL protocols.
> 17. Per protocol outer header retention in inbound processing is
> missing. Preferred options : None/L2/L3/L4/ALL protocols.
>
> Thanks
> Prasad
cc'ed the cavium stakeholders.
More information about the dev
mailing list