From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0F583A00C2; Wed, 23 Feb 2022 18:40:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9113940E5A; Wed, 23 Feb 2022 18:40:47 +0100 (CET) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by mails.dpdk.org (Postfix) with ESMTP id 18A1340DF6 for ; Wed, 23 Feb 2022 18:40:46 +0100 (CET) Received: by mail-qk1-f180.google.com with SMTP id c7so5013801qka.7 for ; Wed, 23 Feb 2022 09:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D2scexI3OFCsMDb9SKlMPlgvStjpQXApNQSw7uFzeTQ=; b=3CCqTI/gKVaaSBu4XgLm5KnD/RJHtetx1012CutGByelyqY+K+BjGbT/qcrAzy8tIk QajY7e1o/WP/BZ7FcvFkTrYaVd7Drsue5Sf2DducoJDy+CmZ8eM9Gc6CJJ6zphAs957r X1YKX7cBwYduixmE24xruD/hHAvhA/I0yQREUaogNCjjKK8oT7L9EhP+jD+o2dtAHduZ l4J6ubgp0MPK/cwSsFQyel4Tg+s+ztXFfW4dhARl9NZXV6+jCr7HT4bn7xHFBfHPOsiX fk/ofMk4MTl1vVugcRNC4c+T74Jhcaoa8j97iCqADYTuyfLmlFdDljcJMg23wrVsiVlD bkSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D2scexI3OFCsMDb9SKlMPlgvStjpQXApNQSw7uFzeTQ=; b=J7hFNzED1/Kb9O7TmGEjn3U5Oet94t9wfHu/QFrOt8GivEvGdSYD1mapg1FIEAW2ef V+92i+3Fm7rUIy2tQyj33gnh11CMvVkOOXgKV1a6bBpDQ2UHjhnxjEJOnL7Lvvd9LsaL jK1HqpCu9lSmvpWYKuCJyQtrFVvJPpkWkTSUrlUdhedvu6dfjniJ9XhlN40ZtWqA5qvE 21JAteGMiAfojBTgSbbG25yWbbOALK4VoZS95yBgLF6JiyyoGmulbjNkbJYARqvoI4yy l73IDy2mH/nWn6hMCdrM/tKMrdNBpFhmA338OWW5qn/JRcct4B4Y4lHD0stSGOVmyNhC AzpQ== X-Gm-Message-State: AOAM530lRSC2c6s1KEVPLWH9bXTsXiUi63IEB9hZvriBqeVZDN33H5hT 9jzvjtol0KKUqLm6k0TiCSsuEWudKPDI3OvbP+ZGFg== X-Google-Smtp-Source: ABdhPJxj3mMGJDozF90D6rVG4ARUTwhtmC70SfLaF7nhnASlY5DCtbmsGcbvH/ZO9+UELrsLfd+eTuuO+IjA7sDVMU4= X-Received: by 2002:a05:620a:48d:b0:49b:56ea:4673 with SMTP id 13-20020a05620a048d00b0049b56ea4673mr482804qkr.713.1645638045383; Wed, 23 Feb 2022 09:40:45 -0800 (PST) MIME-Version: 1.0 References: <20220222181146.28882-1-mk@semihalf.com> <20220223121944.24156-1-mk@semihalf.com> <20220223121944.24156-10-mk@semihalf.com> <733b3d43-00f6-d38b-abef-f0c76e82dbc1@intel.com> In-Reply-To: <733b3d43-00f6-d38b-abef-f0c76e82dbc1@intel.com> From: =?UTF-8?Q?Micha=C5=82_Krawczyk?= Date: Wed, 23 Feb 2022 18:40:34 +0100 Message-ID: Subject: Re: [PATCH v3 09/21] net/ena/base: use optimized memcpy version also on Arm To: Ferruh Yigit Cc: dev , "Brandes, Shai" , upstream@semihalf.com, Dawid Gorecki Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C5=9Br., 23 lut 2022 o 18:26 Ferruh Yigit napisa= =C5=82(a): > > On 2/23/2022 12:19 PM, Michal Krawczyk wrote: > > As the default behavior for arm64 is to alias rte_memcpy as memcpy, ENA > > cannot redefine memcpy as rte_memcpy as it would cause nested > > declaration. > > > > To make it possible to use optimized memcpy in the ena_com layer on Arm= , > > Out of curiosity, do you have any performance measurements for > the optimized memcpy usage? > Unfortunately no - on AWS it's hard to see noticeable performance improvement due to limitations in terms of the PPS number that can be processed at maximum. The basic packet generator applications are mostly idle in that situation. > > the driver now redefines memcpy when it is beneficial: > > * For arm64 only when the flag RTE_ARCH_ARM64_MEMCPY was defined > > * For arm only when the flag RTE_ARCH_ARM_NEON_MEMCPY was defined > > > > Signed-off-by: Michal Krawczyk > > Reviewed-by: Dawid Gorecki > > Reviewed-by: Shai Brandes > > --- > > doc/guides/rel_notes/release_22_03.rst | 1 + > > drivers/net/ena/base/ena_plat_dpdk.h | 7 +++++-- > > 2 files changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_no= tes/release_22_03.rst > > index c8e38d4c70..92490afd60 100644 > > --- a/doc/guides/rel_notes/release_22_03.rst > > +++ b/doc/guides/rel_notes/release_22_03.rst > > @@ -112,6 +112,7 @@ New Features > > * Added new checksum related xstats: ``l3_csum_bad``, ``l4_csum_bad= `` and > > ``l4_csum_good``. > > * Added support for the link status configuration. > > + * Added optimized memcpy support for the ARM platforms. > > > > * **Updated Cisco enic driver.** > > > > diff --git a/drivers/net/ena/base/ena_plat_dpdk.h b/drivers/net/ena/bas= e/ena_plat_dpdk.h > > index 4e7f52881a..41db883c63 100644 > > --- a/drivers/net/ena/base/ena_plat_dpdk.h > > +++ b/drivers/net/ena/base/ena_plat_dpdk.h > > @@ -66,8 +66,11 @@ typedef uint64_t dma_addr_t; > > #define ENA_UDELAY(x) rte_delay_us_block(x) > > > > #define ENA_TOUCH(x) ((void)(x)) > > -/* Avoid nested declaration on arm64, as it may define rte_memcpy as m= emcpy. */ > > -#if defined(RTE_ARCH_X86) > > +/* Redefine memcpy with caution: rte_memcpy can be simply aliased to m= emcpy, so > > + * make the redefinition only if it's safe (and beneficial) to do so. > > + */ > > +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64_MEMCPY) || \ > > + defined(RTE_ARCH_ARM_NEON_MEMCPY) > > #undef memcpy > > #define memcpy rte_memcpy > > #endif > > I can see there is 'ena_plat_dpdk.h', which seems like an osdep header, > > it is possible to use 'ena_memcpy' in the code and in the 'ena_plat_dpdk.= h' > define it as: > #define ena_memcpy rte_memcpy > > > This is just for your information if it helps, usage is up to you. Thanks for the input! It looks like a robust solution, but unfortunately we can't modify other ena_com files which use raw memcpy calls.The preferred approach is to do some work-arounds in the osdep headers instead of modifying the common files.