From patchwork Fri Mar 15 10:44:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arkadiusz Kusztal X-Patchwork-Id: 138433 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 B062843CB8; Fri, 15 Mar 2024 11:44:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 911EE42E8B; Fri, 15 Mar 2024 11:44:42 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by mails.dpdk.org (Postfix) with ESMTP id 258EE4027B for ; Fri, 15 Mar 2024 11:44:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710499482; x=1742035482; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=5wjH4Q4GHC5nmhdJhVvUIOavknTNGlEg1Au0+JVX4JU=; b=ZHHDDPFg+O19Kyqy5LAdxF6RNbI8BtxCrWnSoLR9+vSQyxhD3gMQYIcC EZLSYS1I8jaygTya9i2Ctjc1/DdGNYRSTqnEW3nALf7g6ta6cohdY/hFb BQ0KaTxcDvAnTj5EC7eo950N1eP0Nl6sU6bu9WiRYsAeSPoKn5JmxwSdO yFQZaEJxq0lqgOpMo2wBKcM28NO71H2cEJiwuXRe1KtsO6SkQVsVP7Cq7 Rv4YAgY+JJAmnhaNy3KDS4M53LPObTbJ3mu27xMUXqVK8xgnzYoEnyl2g Op89F/OahXDHqS8/t2DDvSe8ItpxUZhUaDd4Xg7wjwkQka6D0oWYCzoHU Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11013"; a="5300441" X-IronPort-AV: E=Sophos;i="6.07,128,1708416000"; d="scan'208";a="5300441" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2024 03:44:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,128,1708416000"; d="scan'208";a="17300985" Received: from silpixa00400308.ir.intel.com ([10.237.214.154]) by orviesa004.jf.intel.com with ESMTP; 15 Mar 2024 03:44:39 -0700 From: Arkadiusz Kusztal To: dev@dpdk.org Cc: gakhil@marvell.com, ciara.power@intel.com, Arkadiusz Kusztal Subject: [PATCH v2] app/crypto-perf-test: fix unset crc algorithm Date: Fri, 15 Mar 2024 10:44:34 +0000 Message-Id: <20240315104434.2531-1-arkadiuszx.kusztal@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240313145448.26264-1-arkadiuszx.kusztal@intel.com> References: <20240313145448.26264-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 Because net crc api is not thread-safe, setting crc algorithm by the application will prevent race condition in the calc function. Race condition still may occur when any of the threads will call this function again. Function is called with the highest possible SIMD extension, which is AVX512, but if this is not found, CRC API will pick the other highest possible extension, or scalar if no SIMD available. Signed-off-by: Arkadiusz Kusztal Acked-by: Ciara Power --- v2: - narrowed down the case to the docsis only app/test-crypto-perf/main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c index 40c0b4b54f..1b23dd5fb2 100644 --- a/app/test-crypto-perf/main.c +++ b/app/test-crypto-perf/main.c @@ -11,6 +11,7 @@ #include #include #include +#include #ifdef RTE_CRYPTO_SCHEDULER #include #endif @@ -599,6 +600,9 @@ main(int argc, char **argv) goto err; } + if (opts.op_type == CPERF_DOCSIS) + rte_net_crc_set_alg(RTE_NET_CRC_AVX512); + ret = cperf_verify_devices_capabilities(&opts, enabled_cdevs, nb_cryptodevs); if (ret) {