Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2435352rwb; Mon, 19 Sep 2022 05:13:42 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5r2gWUBMJNr1Op3i2u7Rj5LA++TXUtHVveFdFZtkxxyJXbWLRg3Fg8GCYbGCXR3l+3WLfB X-Received: by 2002:a05:6402:33c5:b0:447:e4a3:c930 with SMTP id a5-20020a05640233c500b00447e4a3c930mr14937411edc.401.1663589622007; Mon, 19 Sep 2022 05:13:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663589621; cv=none; d=google.com; s=arc-20160816; b=Eo2ZQEOmDwal44i9SZEPGx3vN0Pa8oPCaHApw1BgALaP9a2bIacJMdKfx8ZdMAyL4I FhzNYrp6Wp5isFYVpQshBj4G4z1D7/Hx3peBkq+dXeHzwXCJzHwsi2/hzjRAeOTmKwhv 0FYI4ygXjim4uSBwZEZ6lKn6OMwIh+G7oGtWQiNHYzKH//4+4Z3tdNLpkACwMs9BHmkp eq4ffnan/f1fO6gtcR72B9/y7fYKHg/MKrWnqBkFmEGlEpkcyCBH1gsTZtHKiNBz8v7P A5dqZZr3b7lAliRscebMwOE87qcNH9nsTSeO8kM3fQ96xg5UXwYb1dDKaO0Dmifi2v5H b3NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=cCxXUHvhJNNZhx8wKBKJDo183+fVJP3Skk/LLP6NJsQ=; b=0cKQArk4FT5V/l97DMpUC/QPKidA8j3cwTWMBToFIEzGR2txR6DEC/Y4Yam5JpOJeu N64aOKVuowmkfeSvUtSRFhdWEnbS/uj2URpwXDHUqAIMvh2fxeIf0wGLeAgCrtJPtIeF Y2Qoq7WcJajvlCLrAYR9IY0mIMBgah5KF0AIEVdEKszM38ss5t0/PEhEfsOeORv6OM+0 iZGRXETzLB2GByhafxdYBs5fy4wP2CwahyXkm3egE3jmoJvUxASeXtJfIUNcD/GM1ggQ fHZKHEHzOxMF8iEa1MS1ksG2EZoZP3E5VnGolylx6NFjZviqR2Gof2sampd1LghjD3aK Hbpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i21-20020a170906251500b0077c6f26aa3bsi17831334ejb.656.2022.09.19.05.13.17; Mon, 19 Sep 2022 05:13:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230071AbiISMIF (ORCPT + 99 others); Mon, 19 Sep 2022 08:08:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230004AbiISMIE (ORCPT ); Mon, 19 Sep 2022 08:08:04 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13E4D2A411; Mon, 19 Sep 2022 05:08:02 -0700 (PDT) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4MWNfK2FVdzpSyh; Mon, 19 Sep 2022 20:05:13 +0800 (CST) Received: from dggpemm500005.china.huawei.com (7.185.36.74) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 19 Sep 2022 20:08:00 +0800 Received: from localhost.localdomain (10.67.164.66) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 19 Sep 2022 20:07:59 +0800 From: Yang Shen To: , CC: , , Subject: [RFC PATCH 0/6] crypto: benchmark - add the crypto benchmark Date: Mon, 19 Sep 2022 20:05:31 +0800 Message-ID: <20220919120537.39258-1-shenyang39@huawei.com> X-Mailer: git-send-email 2.24.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.164.66] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Add crypto benchmark - A tool to help the users quickly get the performance of a algorithm registered in crypto. The tool tries to use the same API to unify the processes of different algorithms. The algorithm can do some private operations in the callbacks. For users, they can see the unified configuration parameters, rather than a set of configuration parameters corresponding to each algorithm. This tool can provide users with the ability to test the performance of algorithms in some specific scenarios. At present, the following parameters are selected for users configuration: block size, block number, thread number, bound numa and request number for per tfm. These parameters can help users simulate approximate business scenarios. For the RFC version, the compression benchmark test is supported. I did some verification on Kunpeng920. The first test case is for zlib-deflate software algorithm. The cpu frequency is 2.6 GHz. I want to show you the influence of these parameters. The configuration is following: run set: algorithm zlib-deflate, algtype CRYPTO_COMPRESS, inputsize 1024, loop 1, numamask 0x0, optype 0, reqnum 1, threadnum 1, time 1. The result is : Crypto benchmark result: throughput pps time 150 MB/s 150 kPP/s 1000 ms And then change the block size: run set: algorithm zlib-deflate, algtype CRYPTO_COMPRESS, inputsize 8192, loop 1, numamask 0x0, optype 0, reqnum 1, threadnum 1, time 1. Crypto benchmark result: throughput pps time 473 MB/s 59 kPP/s 1005 ms run set: algorithm zlib-deflate, algtype CRYPTO_COMPRESS, inputsize 65536, loop 1, numamask 0x0, optype 0, reqnum 1, threadnum 1, time 1. Crypto benchmark result: throughput pps time 421 MB/s 6 kPP/s 1038 ms With the test, users can know that the throughput and pps are both influenced by block size on this server. And the throughput has a peak value while the pps is inverse ratio with bolck size increasing. Due to the software algorithm, thread number will linear increase the result while it is less than cpu number and other parameters have little influence on performance. The second test case is for zlib-deflate hardware. The tested parameters has the same effect on hardware. Here I test the parameter 'reqnum'. The software algorithm register to synchronous process. So here it is useless for software performance. run set: algorithm zlib-deflate, algtype CRYPTO_COMPRESS, inputsize 8192, loop 1, numamask 0x0, optype 0, reqnum 1, threadnum 1, time 1. Crypto benchmark result: throughput pps time 367 MB/s 46 kPP/s 941 ms run set: algorithm zlib-deflate, algtype CRYPTO_COMPRESS, inputsize 8192, loop 1, numamask 0x0, optype 0, reqnum 10, threadnum 1, time 1. Crypto benchmark result: throughput pps time 3507 MB/s 438 kPP/s 1003 ms run set: algorithm zlib-deflate, algtype CRYPTO_COMPRESS, inputsize 8192, loop 1, numamask 0x0, optype 0, reqnum 100, threadnum 1, time 1. Crypto benchmark result: throughput pps time 6318 MB/s 790 kPP/s 1093 ms So we can know that for asynchronous algorithms, request number for per tfm also influence the throughput and pps until a peak value. So with this tool, we can get a quick verification for different platform and get some reference for business scenarios configuration. Yang Shen (6): moduleparams: Add hexulong type parameter crypto: benchmark - add a crypto benchmark tool crytpo: benchmark - support compression/decompresssion crypto: benchmark - add help information crypto: benchmark - add API documentation MAINTAINERS: add crypto benchmark MAINTAINER Documentation/crypto/benchmark.rst | 104 +++++ MAINTAINERS | 7 + crypto/Kconfig | 2 + crypto/Makefile | 5 + crypto/benchmark/Kconfig | 11 + crypto/benchmark/Makefile | 3 + crypto/benchmark/benchmark.c | 599 +++++++++++++++++++++++++++++ crypto/benchmark/benchmark.h | 76 ++++ crypto/benchmark/bm_comp.c | 435 +++++++++++++++++++++ crypto/benchmark/bm_comp.h | 19 + include/linux/moduleparam.h | 7 +- kernel/params.c | 1 + 12 files changed, 1268 insertions(+), 1 deletion(-) create mode 100644 Documentation/crypto/benchmark.rst create mode 100644 crypto/benchmark/Kconfig create mode 100644 crypto/benchmark/Makefile create mode 100644 crypto/benchmark/benchmark.c create mode 100644 crypto/benchmark/benchmark.h create mode 100644 crypto/benchmark/bm_comp.c create mode 100644 crypto/benchmark/bm_comp.h -- 2.24.0