Re: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and ARM

[Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.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).
>>
>> Yes but I think merging them would be a cleaner, number of
>constructors would be
>> one and maybe we could select the best available algorithm on a
>given platform when
>> application requests unsupported one.
>
>Ok, but we can still have one constructor, and two (or more) different
>arch specific headers,
>that would be included into main header conditionally by  #ifdef
>RTE_ARCH_....
>
>>
>> As Yipeng mentioned do you thing having a indirect call instead of
>runtime branch be
>> depreciative in terms of performance?
>
>I think run-time branch by some global var would be much faster than
>indirect function call
>(at least on IA).
>

Ok, makes sense as in a tight loop the run-time branch would be hoisted out.
Let me draft a RFC v2.

>>
>> >
>> >>
>> >> 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.
>> >>
>> >>