From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C588DA0C47; Tue, 12 Oct 2021 11:56:05 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B6EFE410E4; Tue, 12 Oct 2021 11:56:05 +0200 (CEST) Received: from mail-108-mta232.mxroute.com (mail-108-mta232.mxroute.com [136.175.108.232]) by mails.dpdk.org (Postfix) with ESMTP id B2CAA40E0F for ; Tue, 12 Oct 2021 11:56:03 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta232.mxroute.com (ZoneMTA) with ESMTPSA id 17c73ee257a0000b55.004 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 12 Oct 2021 09:55:59 +0000 X-Zone-Loop: fbc90abdc57e5121697c971856bc5a9cbaafe18d98c4 X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VWvPdoWMEgwmzyRdkx6Hy3WrMTQ0kwr7hhmx/xDsHkc=; b=dJfVLuga0e0iH+dGCwdrKaK/J+ Pw8oLKgx13TtdV9Hc4a1ir55l4AzbFg+B3wOFgmrGOZIL/UcV3Gp1NF5QTYFG4Bz7uq1pCZ5+/rLF L+Z9pKynnY2Kr4y6tRNYabqBLnAeNoVWhdzw2crDEdHriPt3NWDqwYqUa271msDnRsphjNEExcDkW U8JWtV1Y2fu6eFBRPp4pKVLd+WH8G66z+tINOIRGfxey7LF7JZD5cBhLysd+FDvLTO3t7TZtGWbQq AgrfOkQo43CPO7mI60xFQEoICTB+FnHmg0FH6jD1Fa50TjRvv0gCzrRZn3fhtiAENRuKVod1jrCXP pDZ4Gvuw==; To: Akhil Goyal , dev@dpdk.org Cc: thomas@monjalon.net, david.marchand@redhat.com, hemant.agrawal@nxp.com, anoobj@marvell.com, pablo.de.lara.guarch@intel.com, fiona.trahe@intel.com, declan.doherty@intel.com, matan@nvidia.com, g.singh@nxp.com, roy.fan.zhang@intel.com, jianjay.zhou@huawei.com, asomalap@amd.com, ruifeng.wang@arm.com, konstantin.ananyev@intel.com, radu.nicolau@intel.com, ajit.khaparde@broadcom.com, rnagadheeraj@marvell.com, adwivedi@marvell.com, ciara.power@intel.com, Stephen Hemminger , "Yigit, Ferruh" References: <20210731181327.660296-1-gakhil@marvell.com> <20211008204516.3497060-1-gakhil@marvell.com> From: "Kinsella, Ray" Message-ID: Date: Tue, 12 Oct 2021 10:55:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211008204516.3497060-1-gakhil@marvell.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, RCPT_COUNT_TWELVE=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0, MID_RHS_MATCH_FROM=0] Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 08/10/2021 21:45, Akhil Goyal wrote: > Remove *_LIST_END enumerators from asymmetric crypto > lib to avoid ABI breakage for every new addition in > enums. > > Signed-off-by: Akhil Goyal > --- > v2: no change > > app/test/test_cryptodev_asym.c | 4 ++-- > drivers/crypto/qat/qat_asym.c | 2 +- > lib/cryptodev/rte_crypto_asym.h | 4 ---- > 3 files changed, 3 insertions(+), 7 deletions(-) > > diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c > index 9d19a6d6d9..603b2e4609 100644 > --- a/app/test/test_cryptodev_asym.c > +++ b/app/test/test_cryptodev_asym.c > @@ -541,7 +541,7 @@ test_one_case(const void *test_case, int sessionless) > printf(" %u) TestCase %s %s\n", test_index++, > tc.modex.description, test_msg); > } else { > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) { > + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) { > if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) { > if (tc.rsa_data.op_type_flags & (1 << i)) { > if (tc.rsa_data.key_exp) { > @@ -1027,7 +1027,7 @@ static inline void print_asym_capa( > rte_crypto_asym_xform_strings[capa->xform_type]); > printf("operation supported -"); > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) { > + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) { > /* check supported operations */ > if (rte_cryptodev_asym_xform_capability_check_optype(capa, i)) > printf(" %s", > diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c > index 85973812a8..026625a4d2 100644 > --- a/drivers/crypto/qat/qat_asym.c > +++ b/drivers/crypto/qat/qat_asym.c > @@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev *dev, > err = -EINVAL; > goto error; > } > - } else if (xform->xform_type >= RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM > || xform->xform_type <= RTE_CRYPTO_ASYM_XFORM_NONE) { > QAT_LOG(ERR, "Invalid asymmetric crypto xform"); > err = -EINVAL; > diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h > index 9c866f553f..5edf658572 100644 > --- a/lib/cryptodev/rte_crypto_asym.h > +++ b/lib/cryptodev/rte_crypto_asym.h > @@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type { > */ > RTE_CRYPTO_ASYM_XFORM_ECPM, > /**< Elliptic Curve Point Multiplication */ > - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > - /**< End of list */ > }; > > /** > @@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type { > /**< DH Public Key generation operation */ > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, > /**< DH Shared Secret compute operation */ > - RTE_CRYPTO_ASYM_OP_LIST_END > }; > > /** > @@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type { > /**< RSA PKCS#1 OAEP padding scheme */ > RTE_CRYPTO_RSA_PADDING_PSS, > /**< RSA PKCS#1 PSS padding scheme */ > - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END > }; > > /** So I am not sure that this is an improvement. The cryptodev issue we had, was that _LIST_END was being used to size arrays. And that broke when new algorithms got added. Is that an issue, in this case? I am not sure that swapping out _LIST_END, and then littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement here. My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not better or worse, than RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE? Interested to hear other thoughts.