From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 3C31FA0471
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <aconole@redhat.com>
To: Fan Zhang <roy.fan.zhang@intel.com>
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: <f7tblvtskqr.fsf@dhcp-25.97.bos.redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Fan Zhang <roy.fan.zhang@intel.com> 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?