Hi Akhil, > -----Original Message----- > From: Akhil Goyal <akhil.go...@nxp.com> > Sent: czwartek, 8 października 2020 21:51 > To: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; dev@dpdk.org > Cc: Trahe, Fiona <fiona.tr...@intel.com>; ruifeng.w...@arm.com; > michae...@marvell.com > Subject: RE: [PATCH v2 4/5] cryptodev: remove list ends from asymmetric crypto > api > > Hi Arek/Fiona, > > > This patch removes RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END, > > RTE_CRYPTO_ASYM_OP_LIST_END, > > RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END > > enumerators from asymmetric crypto API. When asymmetric API will no > > more be experimental adding new entries will be possible without ABI > > breakage. > > I believe XFORM_TYPE, ASYM_OP, and PADDING_TYPE are not going to Change > in near future. Hence LIST_END should not be removed from these Enums. > Adding a LIST END has its own benefits and we should not remove that until we > have a solid reason for it. Moreover, these are experimental. > We should revisit these when we think ASYM is stable.
As for XFORM_TYPE it could be extended by ECDH, even if ECPM is present (as we have DH op enums), I think EdDSA can have its own enum as well. As for asym_op I don't know which way it will go as RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE is distinct case as it is more about generation than computation, this could be clarified in future. As for rsa padding, I agree it fulfills today requirements. Though yes, since it is experimental I will remove asym patch from v3 patchset. > > IMO, we should only remove list ends in algo types. > > Regards, > Akhil
