From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
"Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"Wang, Yipeng1" <yipeng1.wang@intel.com>,
"Gobriel, Sameh" <sameh.gobriel@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
Ruifeng Wang <ruifeng.wang@arm.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and ARM
Date: Mon, 11 May 2020 10:27:44 +0000 [thread overview]
Message-ID: <BYAPR11MB33015C0908201FB6F122C14E9AA10@BYAPR11MB3301.namprd11.prod.outlook.com> (raw)
In-Reply-To: <BYAPR18MB2518C998EB024C61A8923AF8DEA10@BYAPR18MB2518.namprd18.prod.outlook.com>
>
> >> >> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >> >>
> >> >> Merge crc32 hash calculation public API headers for x86 and ARM,
> >> >> split implementations of x86 and ARM into their respective private
> >> >> headers.
> >> >> This reduces the ifdef code clutter while keeping current ABI
> >intact.
> >> >>
> >> >> Although we install `rte_crc_arm64.h` it is not used in any of the lib
> >or
> >> >> drivers layers. All the libs and drivers use `rte_hash_crc.h` which
> >falls
> >> >> back to SW crc32 calculation for ARM platform.
> >> >>
> >> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >> >> ---
> >> >>
> >> >> Currently, if application incorrectly sets CRC32_ARM64 as crc32
> >> >algorithm
> >> >> through `rte_hash_crc_set_alg()` on x86 or vice-versa we fallback
> >to
> >> >algorithm
> >> >> set previously via `rte_hash_crc_set_alg()` instead of setting the
> >best
> >> >> available.
> >> >> This behaviour should probably change to setting the best
> >available
> >> >algorithm
> >> >> and is up for discussion.
> >> >>
> >> >> app/test/test_hash.c | 6 +
> >> >> lib/librte_hash/Makefile | 5 -
> >> >> lib/librte_hash/crc_arm64.h | 67 +++++++++++
> >> >> lib/librte_hash/crc_x86.h | 68 +++++++++++
> >> >> lib/librte_hash/meson.build | 3 +-
> >> >> lib/librte_hash/rte_crc_arm64.h | 183 ------------------------------
> >> >> lib/librte_hash/rte_hash_crc.h | 193 +++++++++++++--------------
> >----
> >> >-
> >> >> 7 files changed, 219 insertions(+), 306 deletions(-)
> >> >> create mode 100644 lib/librte_hash/crc_arm64.h
> >> >> create mode 100644 lib/librte_hash/crc_x86.h
> >> >> delete mode 100644 lib/librte_hash/rte_crc_arm64.h
> >> >>
> >> >> diff --git a/app/test/test_hash.c b/app/test/test_hash.c
> >> >> index afa3a1a3c..7bd457dac 100644
> >> >> --- a/app/test/test_hash.c
> >> >> +++ b/app/test/test_hash.c
> >> >> @@ -195,7 +195,13 @@ test_crc32_hash_alg_equiv(void)
> >> >> }
> >> >>
> >> >> /* Resetting to best available algorithm */
> >> >> +#if defined RTE_ARCH_X86
> >> >> rte_hash_crc_set_alg(CRC32_SSE42_x64);
> >> >> +#elif defined RTE_ARCH_ARM64
> >> >> + rte_hash_crc_set_alg(CRC32_ARM64);
> >> >> +#else
> >> >> + rte_hash_crc_set_alg(CRC32_SW);
> >> >> +#endif
> >> >>
> >> >> if (i == CRC32_ITERATIONS)
> >> >> return 0;
> >> >> diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
> >> >> index ec9f86499..f640afc42 100644
> >> >> --- a/lib/librte_hash/Makefile
> >> >> +++ b/lib/librte_hash/Makefile
> >> >> @@ -19,11 +19,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_HASH) +=
> >> >rte_fbk_hash.c
> >> >> # install this header file
> >> >> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include := rte_hash.h
> >> >> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=
> >rte_hash_crc.h
> >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> >> >> -ifneq ($(findstring RTE_MACHINE_CPUFLAG_CRC32,$(CFLAGS)),)
> >> >> -SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=
> >rte_crc_arm64.h
> >> >> -endif
> >> >> -endif
> >> >> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_jhash.h
> >> >> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_thash.h
> >> >> SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=
> >rte_fbk_hash.h
> >> >> diff --git a/lib/librte_hash/crc_arm64.h
> >b/lib/librte_hash/crc_arm64.h
> >> >> new file mode 100644
> >> >> index 000000000..8e75f8297
> >> >
> >> >Wouldn't that break 'make install T=...'?
> >>
> >> My bad I verified with meson and it was building fine.
> >>
> >> >As now rte_hash_crc.h includes not public headers (crc_x86.h, etc.).
> >> >Same question about external apps, where they would get from
> >these
> >> >headers?
> >>
> >> I think in the next version we can directly have the arch specific
> >functions
> >> Implemented in rte_hash_crc.h. Since its pretty stable code and
> >overhead of extra
> >> ~120 lines.
> >
> >Ok... but why not then just leave arch specific headers, as they are right
> >now?
> >What is wrong with current approach?
>
> The problem is if any application directly includes only rte_crc_arm64.h
> (completely legal) it will break the build.
But we can probably mark rte_crc_arm64.h as internal, and warn users not to
include it directly (same for rte_crc_x86.h and any other arch specific headers).
>
> Example:
>
> diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c
> index 6a799556d..318670940 100644
> --- a/lib/librte_efd/rte_efd.c
> +++ b/lib/librte_efd/rte_efd.c
> @@ -19,7 +19,7 @@
> #include <rte_memcpy.h>
> #include <rte_ring.h>
> #include <rte_jhash.h>
> -#include <rte_hash_crc.h>
> +#include <rte_crc_arm64.h>
> #include <rte_tailq.h>
>
> #include "rte_efd.h"
> (END)
>
> Causes:
>
> ../lib/librte_hash/rte_crc_arm64.h: In function 'rte_hash_crc_set_alg':
> ../lib/librte_hash/rte_crc_arm64.h:77:7: error: 'CRC32_ARM64' undeclared (first use in this function)
> 77 | case CRC32_ARM64:
> | ^~~~~~~~~~~
> ../lib/librte_hash/rte_crc_arm64.h:77:7: note: each undeclared identifier is reported only once for each function it appears in
> ../lib/librte_hash/rte_crc_arm64.h:79:10: error: 'CRC32_SW' undeclared (first use in this function)
> 79 | alg = CRC32_SW;
> | ^~~~~~~~
> ../lib/librte_hash/rte_crc_arm64.h:82:3: error: 'crc32_alg' undeclared (first use in this function)
> 82 | crc32_alg = alg;
> | ^~~~~~~~~
> ../lib/librte_hash/rte_crc_arm64.h: In function 'rte_hash_crc_init_alg':
> ../lib/librte_hash/rte_crc_arm64.h:92:23: error: 'CRC32_ARM64' undeclared (first use in this function)
> 92 | rte_hash_crc_set_alg(CRC32_ARM64);
>
> Thanks,
> Pavan.
>
>
next prev parent reply other threads:[~2020-05-11 10:27 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 18:05 pbhagavatula
2020-04-30 9:14 ` Van Haaren, Harry
2020-04-30 9:27 ` Pavan Nikhilesh Bhagavatula
2020-05-06 22:02 ` Wang, Yipeng1
2020-05-10 22:49 ` Pavan Nikhilesh Bhagavatula
2020-05-08 12:55 ` Ananyev, Konstantin
2020-05-10 22:53 ` Pavan Nikhilesh Bhagavatula
2020-05-11 9:46 ` Ananyev, Konstantin
2020-05-11 10:23 ` Pavan Nikhilesh Bhagavatula
2020-05-11 10:27 ` Ananyev, Konstantin [this message]
2020-05-11 10:57 ` Pavan Nikhilesh Bhagavatula
2020-05-11 12:10 ` Ananyev, Konstantin
2020-05-11 12:32 ` Pavan Nikhilesh Bhagavatula
2020-05-12 20:40 ` [dpdk-dev] [RFC v2] " pbhagavatula
2020-05-13 3:04 ` Ruifeng Wang
2020-05-13 13:22 ` Ananyev, Konstantin
2021-10-03 23:00 ` [dpdk-dev] [PATCH v3 1/2] hash: split x86 and SW hash CRC intrinsics pbhagavatula
2021-10-03 23:00 ` [dpdk-dev] [PATCH v3 2/2] hash: unify crc32 selection for x86 and Arm pbhagavatula
2021-10-04 5:52 ` [dpdk-dev] [PATCH v4 1/2] hash: split x86 and SW hash CRC intrinsics pbhagavatula
2021-10-04 5:52 ` [dpdk-dev] [PATCH v4 2/2] hash: unify crc32 selection for x86 and Arm pbhagavatula
2021-10-18 9:21 ` Ruifeng Wang
2021-11-05 10:10 ` [dpdk-dev] [PATCH v5 1/2] hash: split x86 and SW hash CRC intrinsics pbhagavatula
2021-11-05 10:10 ` [dpdk-dev] [PATCH v5 2/2] hash: unify crc32 selection for x86 and Arm pbhagavatula
2022-01-04 9:12 ` Ruifeng Wang
2022-04-08 9:16 ` David Marchand
2021-11-16 14:57 ` [dpdk-dev] [PATCH v5 1/2] hash: split x86 and SW hash CRC intrinsics David Marchand
2022-04-27 13:35 ` [PATCH v6 " Pavan Nikhilesh
2022-04-27 13:35 ` [PATCH v6 2/2] hash: unify crc32 selection for x86 and Arm Pavan Nikhilesh
2022-04-27 15:22 ` [PATCH v7 1/2] hash: split x86 and SW hash CRC intrinsics Pavan Nikhilesh
2022-04-27 15:22 ` [PATCH v7 2/2] hash: unify crc32 selection for x86 and Arm Pavan Nikhilesh
2022-04-29 7:19 ` Ruifeng Wang
2022-04-29 7:18 ` [PATCH v7 1/2] hash: split x86 and SW hash CRC intrinsics Ruifeng Wang
2022-04-29 13:29 ` David Marchand
2022-04-29 15:56 ` [EXT] " Pavan Nikhilesh Bhagavatula
2022-04-29 16:16 ` [PATCH v8 " Pavan Nikhilesh
2022-04-29 16:17 ` [PATCH v8 2/2] hash: unify crc32 selection for x86 and Arm Pavan Nikhilesh
2022-05-03 14:33 ` David Marchand
2022-05-04 2:53 ` Wang, Yipeng1
2022-05-11 14:23 ` David Marchand
2022-05-04 2:19 ` [PATCH v8 1/2] hash: split x86 and SW hash CRC intrinsics Wang, Yipeng1
2022-05-13 18:27 ` [PATCH v9 " pbhagavatula
2022-05-13 18:27 ` [PATCH v9 2/2] hash: unify crc32 selection for x86 and Arm pbhagavatula
2022-05-19 14:20 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BYAPR11MB33015C0908201FB6F122C14E9AA10@BYAPR11MB3301.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=pbhagavatula@marvell.com \
--cc=ruifeng.wang@arm.com \
--cc=sameh.gobriel@intel.com \
--cc=thomas@monjalon.net \
--cc=yipeng1.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).