From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3C31FA0471 for ; Mon, 9 Sep 2019 14:43:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EC1351D127; Mon, 9 Sep 2019 14:43:43 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 8F2551BF47 for ; Mon, 9 Sep 2019 14:43:42 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3E6EA46C22; Mon, 9 Sep 2019 12:43:41 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 519F26012C; Mon, 9 Sep 2019 12:43:41 +0000 (UTC) From: Aaron Conole To: Fan Zhang Cc: dev@dpdk.org, konstantin.ananyev@intel.com, declan.doherty@intel.com, akhil.goyal@nxp.com References: <20190903154046.55992-1-roy.fan.zhang@intel.com> <20190906131330.40185-1-roy.fan.zhang@intel.com> Date: Mon, 09 Sep 2019 08:43:40 -0400 In-Reply-To: <20190906131330.40185-1-roy.fan.zhang@intel.com> (Fan Zhang's message of "Fri, 6 Sep 2019 14:13:20 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.68]); Mon, 09 Sep 2019 12:43:42 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 00/10] security: add software synchronous crypto process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Fan Zhang writes: > This RFC patch adds a way to rte_security to process symmetric crypto > workload in bulk synchronously for SW crypto devices. > > Originally both SW and HW crypto PMDs works under rte_cryptodev to > process the crypto workload asynchronously. This way provides uniformity > to both PMD types but also introduce unnecessary performance penalty to > SW PMDs such as extra SW ring enqueue/dequeue steps to "simulate" > asynchronous working manner and unnecessary HW addresses computation. > > We introduce a new way for SW crypto devices that perform crypto operation > synchronously with only fields required for the computation as input. > > In rte_security, a new action type "RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO" > is introduced. This action type allows the burst of symmetric crypto > workload using the same algorithm, key, and direction being processed by > CPU cycles synchronously. This flexible action type does not require > external hardware involvement. > > This patch also includes the announcement of a new API > "rte_security_process_cpu_crypto_bulk". With this API the packet is sent = to > the crypto device for symmetric crypto processing. The device will encrypt > or decrypt the buffer based on the session data specified and preprocessed > in the security session. Different than the inline or lookaside modes, wh= en > the function exits, the user will expect the buffers are either processed > successfully, or having the error number assigned to the appropriate index > of the status array. > > The proof-of-concept AESNI-GCM and AESNI-MB SW PMDs are updated with the > support of this new method. To demonstrate the performance gain with > this method 2 simple performance evaluation apps under unit-test are added > "app/test: security_aesni_gcm_perftest/security_aesni_mb_perftest". The > users can freely compare their results against crypto perf application > results. > > In the end, the ipsec library and ipsec-secgw sample application are also > updated to support this feature. Several test scripts are added to the > ipsec-secgw test-suite to prove the correctness of the implementation. > > Fan Zhang (10): > security: introduce CPU Crypto action type and API > crypto/aesni_gcm: add rte_security handler > app/test: add security cpu crypto autotest > app/test: add security cpu crypto perftest > crypto/aesni_mb: add rte_security handler > app/test: add aesni_mb security cpu crypto autotest > app/test: add aesni_mb security cpu crypto perftest > ipsec: add rte_security cpu_crypto action support > examples/ipsec-secgw: add security cpu_crypto action support > doc: update security cpu process description > Hi Fan, This series has problem on aarch64: ../app/test/test_security_cpu_crypto.c:626:16: error: implicit declarati= on of function =E2=80=98rte_get_tsc_hz=E2=80=99 [-Werror=3Dimplicit-functio= n-declaration] uint64_t hz =3D rte_get_tsc_hz(), time_start, time_now; ^ ../app/test/test_security_cpu_crypto.c:679:16: error: implicit declarati= on of function =E2=80=98rte_rdtsc=E2=80=99 [-Werror=3Dimplicit-function-dec= laration] time_start =3D rte_rdtsc(); ^ ../app/test/test_security_cpu_crypto.c:711:16: error: implicit declarati= on of function =E2=80=98rte_get_timer_cycles=E2=80=99 [-Werror=3Dimplicit-f= unction-declaration] time_start =3D rte_get_timer_cycles(); ^ I'm not sure best way to address this in the test - maybe there's a better API to use for getting the cycles?