From patchwork Fri May 20 05:54:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arkadiusz Kusztal X-Patchwork-Id: 111495 X-Patchwork-Delegate: gakhil@marvell.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 505BFA0503; Fri, 20 May 2022 09:03:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1E23C42BAB; Fri, 20 May 2022 09:03:03 +0200 (CEST) Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 8769A42BAB for ; Fri, 20 May 2022 09:03:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653030180; x=1684566180; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=K4FXkpp4/GkEOqpqGeVr5tTFBk9X0Ltuk8UdciNtUi8=; b=eUu1htZX8LjuxK/jlnuKxhM3ZLJANbD74695CcEDIur3MzCV5fWaMXqw 2iW+oRFTYNE1Ims8pgBwBzn153r7y7ecxwwMnyUXRGIhR1WqD3gj6zxOT gDpTyCNToDLXhDFfODVttZht3I70RYhpZrfey83pFFb22LqqxjvBahRlZ QEL/i8BczU6Fqb2StDCGkd6eDam9npESLemkKhdICTnes7AOsbh3Utdpu nvJsckqjqAyQO01f9YEQqfj6SBqphzkNlL6OjkvLANipryWjL5a8fyzh4 4/UYvA/Rf+8rICEPqS9T3SaM3cA1u30P5u57IiSJCSUjA9re3rYLWJ606 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10352"; a="333140300" X-IronPort-AV: E=Sophos;i="5.91,238,1647327600"; d="scan'208";a="333140300" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2022 00:03:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,238,1647327600"; d="scan'208";a="599058182" Received: from silpixa00399302.ir.intel.com ([10.237.214.136]) by orsmga008.jf.intel.com with ESMTP; 20 May 2022 00:02:58 -0700 From: Arek Kusztal To: dev@dpdk.org Cc: gakhil@marvell.com, anoobj@marvell.com, roy.fan.zhang@intel.com, Arek Kusztal Subject: [PATCH 11/40] cryptodev: remove asym crypto next xform Date: Fri, 20 May 2022 06:54:16 +0100 Message-Id: <20220520055445.40063-12-arkadiuszx.kusztal@intel.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20220520055445.40063-1-arkadiuszx.kusztal@intel.com> References: <20220520055445.40063-1-arkadiuszx.kusztal@intel.com> 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 - removed asymnetric crypto xform next field. Rationale behind having chaining in symmetric crypto was a fact that encryption and authentication are usually done on the same set of data independent of algorithm. HW usually will be able to handle it in one PCI call. In asymmetric there is no such relation between algorithms, therefore next field would be useless. Signed-off-by: Arek Kusztal --- lib/cryptodev/rte_crypto_asym.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa 100644 --- a/lib/cryptodev/rte_crypto_asym.h +++ b/lib/cryptodev/rte_crypto_asym.h @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param { * Structure describing asym xforms. */ struct rte_crypto_asym_xform { - struct rte_crypto_asym_xform *next; - /**< Pointer to next xform to set up xform chain.*/ enum rte_crypto_asym_xform_type xform_type; /**< Asymmetric crypto transform */