DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.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:57:07 +0000	[thread overview]
Message-ID: <BYAPR18MB251884DE1D9789594A267593DEA10@BYAPR18MB2518.namprd18.prod.outlook.com> (raw)
In-Reply-To: <BYAPR11MB33015C0908201FB6F122C14E9AA10@BYAPR11MB3301.namprd11.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).

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.

As Yipeng mentioned do you thing having a indirect call instead of runtime branch be 
depreciative in terms of performance?

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


  reply	other threads:[~2020-05-11 10:57 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
2020-05-11 10:57           ` Pavan Nikhilesh Bhagavatula [this message]
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=BYAPR18MB251884DE1D9789594A267593DEA10@BYAPR18MB2518.namprd18.prod.outlook.com \
    --to=pbhagavatula@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.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).