[v7,1/6] lib/eal: implement the family of PMD bit operation APIs
diff mbox series

Message ID 20200309095410.28983-2-joyce.kong@arm.com
State Superseded, archived
Delegated to: David Marchand
Headers show
Series
  • implement common rte bit operation APIs in PMDs
Related show

Checks

Context Check Description
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-testing fail Testing issues
ci/iol-intel-Performance fail Performance Testing issues
ci/checkpatch success coding style OK

Commit Message

Joyce Kong March 9, 2020, 9:54 a.m. UTC
Bitwise operation APIs are defined and used in a lot of PMDs,
which caused a huge code duplication. To reduce duplication,
this patch consolidates them into a common API family.

Signed-off-by: Joyce Kong <joyce.kong@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Phil Yang <phil.yang@arm.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 MAINTAINERS                                   |   4 +
 doc/api/doxy-api-index.md                     |   5 +-
 drivers/net/Makefile                          |   1 +
 lib/librte_eal/common/Makefile                |   1 +
 .../common/include/rte_pmd_bitops.h           | 257 ++++++++++++++++++
 lib/librte_eal/common/meson.build             |   3 +-
 6 files changed, 268 insertions(+), 3 deletions(-)
 create mode 100644 lib/librte_eal/common/include/rte_pmd_bitops.h

Comments

Stephen Hemminger March 9, 2020, 3:50 p.m. UTC | #1
On Mon,  9 Mar 2020 17:54:05 +0800
Joyce Kong <joyce.kong@arm.com> wrote:

> /**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Return the original bit from a 64-bit value, then clear it to 0 without
> + * memory ordering.
> + *
> + * @param nr
> + *   The target bit to get and clear.
> + * @param addr
> + *   The address holding the bit.
> + * @return
> + *   The original bit.
> + */
> +__rte_experimental
> +static inline uint64_t
> +rte_test_and_clear_bit64_relaxed(unsigned int nr, volatile uint64_t *addr)
> +{
> +	RTE_ASSERT(nr < 64);
> +
> +	uint64_t mask = UINT64_C(1) << nr;
> +	uint64_t val = *addr;
> +	*addr = (*addr) & (~mask);
> +	return val & mask;
> +}
> +

This is not thread safe. You should use the existing GCC builtins.
Thomas Monjalon March 31, 2020, 10:35 p.m. UTC | #2
Hi,

09/03/2020 10:54, Joyce Kong:
> Bitwise operation APIs are defined and used in a lot of PMDs,
> which caused a huge code duplication.

Statistics of the series: 653 insertions(+), 326 deletions(-)
I would not say it is a huge duplication.

> To reduce duplication,
> this patch consolidates them into a common API family.
[...]
> +PMD Bitops
> +M: Joyce Kong <joyce.kong@arm.com>
> +F: lib/librte_eal/common/include/rte_pmd_bitops.h

Why is it called PMD bitops and not simply bitops?
Gavin Hu April 1, 2020, 8:27 a.m. UTC | #3
Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, April 1, 2020 6:36 AM
> To: Joyce Kong <Joyce.Kong@arm.com>
> Cc: stephen@networkplumber.org; david.marchand@redhat.com;
> mb@smartsharesystems.com; jerinj@marvell.com;
> bruce.richardson@intel.com; ravi1.kumar@amd.com; rmody@marvell.com;
> shshaikh@marvell.com; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; Gavin Hu <Gavin.Hu@arm.com>; nd
> <nd@arm.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/6] lib/eal: implement the family of PMD
> bit operation APIs
> 
> Hi,
> 
> 09/03/2020 10:54, Joyce Kong:
> > Bitwise operation APIs are defined and used in a lot of PMDs,
> > which caused a huge code duplication.
> 
> Statistics of the series: 653 insertions(+), 326 deletions(-)
> I would not say it is a huge duplication.
We did not include all PMDs, just a few for piloting and seeking opinions.
It is a huge duplication when counting all the PMDs.
> 
> > To reduce duplication,
> > this patch consolidates them into a common API family.
> [...]
> > +PMD Bitops
> > +M: Joyce Kong <joyce.kong@arm.com>
> > +F: lib/librte_eal/common/include/rte_pmd_bitops.h
> 
> Why is it called PMD bitops and not simply bitops?
The scope of these APIs are decreased to PMD use only, for libraries/applications, it is recommended to use C11 directly as there are complications of more ordering models involved. 
>
Thomas Monjalon April 1, 2020, 9:45 a.m. UTC | #4
01/04/2020 10:27, Gavin Hu:
> Hi Thomas,
> 
> From: Thomas Monjalon <thomas@monjalon.net>
> > 
> > Hi,
> > 
> > 09/03/2020 10:54, Joyce Kong:
> > > Bitwise operation APIs are defined and used in a lot of PMDs,
> > > which caused a huge code duplication.
> > 
> > Statistics of the series: 653 insertions(+), 326 deletions(-)
> > I would not say it is a huge duplication.
> We did not include all PMDs, just a few for piloting and seeking opinions.
> It is a huge duplication when counting all the PMDs.
> > 
> > > To reduce duplication,
> > > this patch consolidates them into a common API family.
> > [...]
> > > +PMD Bitops
> > > +M: Joyce Kong <joyce.kong@arm.com>
> > > +F: lib/librte_eal/common/include/rte_pmd_bitops.h
> > 
> > Why is it called PMD bitops and not simply bitops?
> 
> The scope of these APIs are decreased to PMD use only, for libraries/applications, it is recommended to use C11 directly as there are complications of more ordering models involved. 

OK, but PMD means nothing, except this is where it is used *now*.
Please describe and name the API with memory ordering words.
Gavin Hu April 2, 2020, 7:20 a.m. UTC | #5
Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, April 1, 2020 5:45 PM
> To: Joyce Kong <Joyce.Kong@arm.com>; Gavin Hu <Gavin.Hu@arm.com>
> Cc: stephen@networkplumber.org; david.marchand@redhat.com;
> mb@smartsharesystems.com; jerinj@marvell.com;
> bruce.richardson@intel.com; ravi1.kumar@amd.com; rmody@marvell.com;
> shshaikh@marvell.com; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; nd <nd@arm.com>; dev@dpdk.org; nd
> <nd@arm.com>
> Subject: Re: [dpdk-dev] [PATCH v7 1/6] lib/eal: implement the family of PMD
> bit operation APIs
> 
> 01/04/2020 10:27, Gavin Hu:
> > Hi Thomas,
> >
> > From: Thomas Monjalon <thomas@monjalon.net>
> > >
> > > Hi,
> > >
> > > 09/03/2020 10:54, Joyce Kong:
> > > > Bitwise operation APIs are defined and used in a lot of PMDs,
> > > > which caused a huge code duplication.
> > >
> > > Statistics of the series: 653 insertions(+), 326 deletions(-)
> > > I would not say it is a huge duplication.
> > We did not include all PMDs, just a few for piloting and seeking opinions.
> > It is a huge duplication when counting all the PMDs.
> > >
> > > > To reduce duplication,
> > > > this patch consolidates them into a common API family.
> > > [...]
> > > > +PMD Bitops
> > > > +M: Joyce Kong <joyce.kong@arm.com>
> > > > +F: lib/librte_eal/common/include/rte_pmd_bitops.h
> > >
> > > Why is it called PMD bitops and not simply bitops?
> >
> > The scope of these APIs are decreased to PMD use only, for
> libraries/applications, it is recommended to use C11 directly as there are
> complications of more ordering models involved.
> 
> OK, but PMD means nothing, except this is where it is used *now*.
> Please describe and name the API with memory ordering words.
Will remove 'PMD' in v8.
The APIs were already named with a '_relaxed' suffix, for example 'rte_get_bit64_relaxed'. 
According to Honnappa, this patch set just address PMD's requirement, and the current PMDs are not using C11, so only '_relaxed' version is offered.
http://inbox.dpdk.org/dev/VE1PR08MB514983C3200859B27F166EBB983F0@VE1PR08MB5149.eurprd08.prod.outlook.com/
Thomas Monjalon April 2, 2020, 8:07 a.m. UTC | #6
02/04/2020 09:20, Gavin Hu:
> Hi Thomas,
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Wednesday, April 1, 2020 5:45 PM
> > To: Joyce Kong <Joyce.Kong@arm.com>; Gavin Hu <Gavin.Hu@arm.com>
> > Cc: stephen@networkplumber.org; david.marchand@redhat.com;
> > mb@smartsharesystems.com; jerinj@marvell.com;
> > bruce.richardson@intel.com; ravi1.kumar@amd.com; rmody@marvell.com;
> > shshaikh@marvell.com; xuanziyang2@huawei.com;
> > cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Honnappa
> > Nagarahalli <Honnappa.Nagarahalli@arm.com>; Phil Yang
> > <Phil.Yang@arm.com>; nd <nd@arm.com>; dev@dpdk.org; nd
> > <nd@arm.com>
> > Subject: Re: [dpdk-dev] [PATCH v7 1/6] lib/eal: implement the family of PMD
> > bit operation APIs
> > 
> > 01/04/2020 10:27, Gavin Hu:
> > > Hi Thomas,
> > >
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > >
> > > > Hi,
> > > >
> > > > 09/03/2020 10:54, Joyce Kong:
> > > > > Bitwise operation APIs are defined and used in a lot of PMDs,
> > > > > which caused a huge code duplication.
> > > >
> > > > Statistics of the series: 653 insertions(+), 326 deletions(-)
> > > > I would not say it is a huge duplication.
> > > We did not include all PMDs, just a few for piloting and seeking opinions.
> > > It is a huge duplication when counting all the PMDs.
> > > >
> > > > > To reduce duplication,
> > > > > this patch consolidates them into a common API family.
> > > > [...]
> > > > > +PMD Bitops
> > > > > +M: Joyce Kong <joyce.kong@arm.com>
> > > > > +F: lib/librte_eal/common/include/rte_pmd_bitops.h
> > > >
> > > > Why is it called PMD bitops and not simply bitops?
> > >
> > > The scope of these APIs are decreased to PMD use only, for
> > libraries/applications, it is recommended to use C11 directly as there are
> > complications of more ordering models involved.
> > 
> > OK, but PMD means nothing, except this is where it is used *now*.
> > Please describe and name the API with memory ordering words.
> Will remove 'PMD' in v8.
> The APIs were already named with a '_relaxed' suffix, for example 'rte_get_bit64_relaxed'. 
> According to Honnappa, this patch set just address PMD's requirement, and the current PMDs are not using C11, so only '_relaxed' version is offered.
> http://inbox.dpdk.org/dev/VE1PR08MB514983C3200859B27F166EBB983F0@VE1PR08MB5149.eurprd08.prod.outlook.com/

So why not calling this component "relaxed bitops"?
Jerin Jacob April 2, 2020, 8:11 a.m. UTC | #7
On Thu, Apr 2, 2020 at 1:37 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 02/04/2020 09:20, Gavin Hu:
> > Hi Thomas,
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Wednesday, April 1, 2020 5:45 PM
> > > To: Joyce Kong <Joyce.Kong@arm.com>; Gavin Hu <Gavin.Hu@arm.com>
> > > Cc: stephen@networkplumber.org; david.marchand@redhat.com;
> > > mb@smartsharesystems.com; jerinj@marvell.com;
> > > bruce.richardson@intel.com; ravi1.kumar@amd.com; rmody@marvell.com;
> > > shshaikh@marvell.com; xuanziyang2@huawei.com;
> > > cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Honnappa
> > > Nagarahalli <Honnappa.Nagarahalli@arm.com>; Phil Yang
> > > <Phil.Yang@arm.com>; nd <nd@arm.com>; dev@dpdk.org; nd
> > > <nd@arm.com>
> > > Subject: Re: [dpdk-dev] [PATCH v7 1/6] lib/eal: implement the family of PMD
> > > bit operation APIs
> > >
> > > 01/04/2020 10:27, Gavin Hu:
> > > > Hi Thomas,
> > > >
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > >
> > > > > Hi,
> > > > >
> > > > > 09/03/2020 10:54, Joyce Kong:
> > > > > > Bitwise operation APIs are defined and used in a lot of PMDs,
> > > > > > which caused a huge code duplication.
> > > > >
> > > > > Statistics of the series: 653 insertions(+), 326 deletions(-)
> > > > > I would not say it is a huge duplication.
> > > > We did not include all PMDs, just a few for piloting and seeking opinions.
> > > > It is a huge duplication when counting all the PMDs.
> > > > >
> > > > > > To reduce duplication,
> > > > > > this patch consolidates them into a common API family.
> > > > > [...]
> > > > > > +PMD Bitops
> > > > > > +M: Joyce Kong <joyce.kong@arm.com>
> > > > > > +F: lib/librte_eal/common/include/rte_pmd_bitops.h

Change to lib/librte_eal/include/rte_pmd_bitops.h. Check top of tree.

> > > > >
> > > > > Why is it called PMD bitops and not simply bitops?
> > > >
> > > > The scope of these APIs are decreased to PMD use only, for
> > > libraries/applications, it is recommended to use C11 directly as there are
> > > complications of more ordering models involved.
> > >
> > > OK, but PMD means nothing, except this is where it is used *now*.
> > > Please describe and name the API with memory ordering words.
> > Will remove 'PMD' in v8.
> > The APIs were already named with a '_relaxed' suffix, for example 'rte_get_bit64_relaxed'.
> > According to Honnappa, this patch set just address PMD's requirement, and the current PMDs are not using C11, so only '_relaxed' version is offered.
> > http://inbox.dpdk.org/dev/VE1PR08MB514983C3200859B27F166EBB983F0@VE1PR08MB5149.eurprd08.prod.outlook.com/
>
> So why not calling this component "relaxed bitops"?

In the future, we can extend to more memory orders as needed. IMO,
Just changing to rte_bitops.h is enough.

>
>
>
>
Gavin Hu April 2, 2020, 9:02 a.m. UTC | #8
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, April 2, 2020 4:12 PM
> To: thomas@monjalon.net
> Cc: Joyce Kong <Joyce.Kong@arm.com>; Gavin Hu <Gavin.Hu@arm.com>;
> stephen@networkplumber.org; david.marchand@redhat.com;
> mb@smartsharesystems.com; jerinj@marvell.com;
> bruce.richardson@intel.com; ravi1.kumar@amd.com; rmody@marvell.com;
> shshaikh@marvell.com; xuanziyang2@huawei.com;
> cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; nd <nd@arm.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/6] lib/eal: implement the family of PMD
> bit operation APIs
> 
> On Thu, Apr 2, 2020 at 1:37 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> >
> > 02/04/2020 09:20, Gavin Hu:
> > > Hi Thomas,
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Sent: Wednesday, April 1, 2020 5:45 PM
> > > > To: Joyce Kong <Joyce.Kong@arm.com>; Gavin Hu
> <Gavin.Hu@arm.com>
> > > > Cc: stephen@networkplumber.org; david.marchand@redhat.com;
> > > > mb@smartsharesystems.com; jerinj@marvell.com;
> > > > bruce.richardson@intel.com; ravi1.kumar@amd.com;
> rmody@marvell.com;
> > > > shshaikh@marvell.com; xuanziyang2@huawei.com;
> > > > cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com;
> Honnappa
> > > > Nagarahalli <Honnappa.Nagarahalli@arm.com>; Phil Yang
> > > > <Phil.Yang@arm.com>; nd <nd@arm.com>; dev@dpdk.org; nd
> > > > <nd@arm.com>
> > > > Subject: Re: [dpdk-dev] [PATCH v7 1/6] lib/eal: implement the family of
> PMD
> > > > bit operation APIs
> > > >
> > > > 01/04/2020 10:27, Gavin Hu:
> > > > > Hi Thomas,
> > > > >
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > 09/03/2020 10:54, Joyce Kong:
> > > > > > > Bitwise operation APIs are defined and used in a lot of PMDs,
> > > > > > > which caused a huge code duplication.
> > > > > >
> > > > > > Statistics of the series: 653 insertions(+), 326 deletions(-)
> > > > > > I would not say it is a huge duplication.
> > > > > We did not include all PMDs, just a few for piloting and seeking
> opinions.
> > > > > It is a huge duplication when counting all the PMDs.
> > > > > >
> > > > > > > To reduce duplication,
> > > > > > > this patch consolidates them into a common API family.
> > > > > > [...]
> > > > > > > +PMD Bitops
> > > > > > > +M: Joyce Kong <joyce.kong@arm.com>
> > > > > > > +F: lib/librte_eal/common/include/rte_pmd_bitops.h
> 
> Change to lib/librte_eal/include/rte_pmd_bitops.h. Check top of tree.
Yes, will rebase in v8.
> 
> > > > > >
> > > > > > Why is it called PMD bitops and not simply bitops?
> > > > >
> > > > > The scope of these APIs are decreased to PMD use only, for
> > > > libraries/applications, it is recommended to use C11 directly as there
> are
> > > > complications of more ordering models involved.
> > > >
> > > > OK, but PMD means nothing, except this is where it is used *now*.
> > > > Please describe and name the API with memory ordering words.
> > > Will remove 'PMD' in v8.
> > > The APIs were already named with a '_relaxed' suffix, for example
> 'rte_get_bit64_relaxed'.
> > > According to Honnappa, this patch set just address PMD's requirement,
> and the current PMDs are not using C11, so only '_relaxed' version is
> offered.
> > >
> http://inbox.dpdk.org/dev/VE1PR08MB514983C3200859B27F166EBB983F0
> @VE1PR08MB5149.eurprd08.prod.outlook.com/
> >
> > So why not calling this component "relaxed bitops"?
> 
> In the future, we can extend to more memory orders as needed. IMO,
> Just changing to rte_bitops.h is enough.
Ok, will change to rte_bitops.h to leave room for future extension. 
> 
> >
> >
> >
> >

Patch
diff mbox series

diff --git a/MAINTAINERS b/MAINTAINERS
index f4e0ed8e0..071daf887 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -244,6 +244,10 @@  M: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
 F: lib/librte_eal/common/include/rte_bitmap.h
 F: app/test/test_bitmap.c
 
+PMD Bitops
+M: Joyce Kong <joyce.kong@arm.com>
+F: lib/librte_eal/common/include/rte_pmd_bitops.h
+
 MCSlock - EXPERIMENTAL
 M: Phil Yang <phil.yang@arm.com>
 F: lib/librte_eal/common/include/generic/rte_mcslock.h
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index dff496be0..64ab142f3 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -35,6 +35,7 @@  The public API headers are grouped by topics:
   [vfio]               (@ref rte_vfio.h)
 
 - **device specific**:
+  [pmd_bitops]         (@ref rte_pmd_bitops.h),
   [softnic]            (@ref rte_eth_softnic.h),
   [bond]               (@ref rte_eth_bond.h),
   [vhost]              (@ref rte_vhost.h),
@@ -133,12 +134,12 @@  The public API headers are grouped by topics:
   [BPF]                (@ref rte_bpf.h)
 
 - **containers**:
+  [bitmap]             (@ref rte_bitmap.h),
   [mbuf]               (@ref rte_mbuf.h),
   [mbuf pool ops]      (@ref rte_mbuf_pool_ops.h),
   [ring]               (@ref rte_ring.h),
   [stack]              (@ref rte_stack.h),
-  [tailq]              (@ref rte_tailq.h),
-  [bitmap]             (@ref rte_bitmap.h)
+  [tailq]              (@ref rte_tailq.h)
 
 - **packet framework**:
   * [port]             (@ref rte_port.h):
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 4a7f155fc..1a3202d1c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -3,6 +3,7 @@ 
 
 include $(RTE_SDK)/mk/rte.vars.mk
 
+INC := rte_pmd_bitops.h
 # set in mk/toolchain/xxx/rte.toolchain-compat.mk
 ifeq ($(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD),d)
         $(warning thunderx pmd is not supported by old compilers)
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index c2c6d92cd..24a5ae94f 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -19,6 +19,7 @@  INC += rte_malloc.h rte_keepalive.h rte_time.h
 INC += rte_service.h rte_service_component.h
 INC += rte_bitmap.h rte_vfio.h rte_hypervisor.h rte_test.h
 INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h
+INC += rte_pmd_bitops.h
 
 GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
 GENERIC_INC += rte_memcpy.h rte_cpuflags.h
diff --git a/lib/librte_eal/common/include/rte_pmd_bitops.h b/lib/librte_eal/common/include/rte_pmd_bitops.h
new file mode 100644
index 000000000..b7801e01e
--- /dev/null
+++ b/lib/librte_eal/common/include/rte_pmd_bitops.h
@@ -0,0 +1,257 @@ 
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Arm Limited
+ */
+
+#ifndef _RTE_PMD_BITOPS_H_
+#define _RTE_PMD_BITOPS_H_
+
+/**
+ * @file
+ * Bit Operations
+ *
+ * This file defines a API for bit operations without/with memory ordering.
+ */
+
+#include <stdint.h>
+#include <rte_debug.h>
+#include <rte_compat.h>
+
+/*---------------------------- 32 bit operations ----------------------------*/
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Get the target bit from a 32-bit value without memory ordering.
+ *
+ * @param nr
+ *   The target bit to get.
+ * @param addr
+ *   The address holding the bit.
+ * @return
+ *   The target bit.
+ */
+__rte_experimental
+static inline uint32_t
+rte_get_bit32_relaxed(unsigned int nr, volatile uint32_t *addr)
+{
+	RTE_ASSERT(nr < 32);
+
+	uint32_t mask = UINT32_C(1) << nr;
+	return (*addr) & mask;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Set the target bit in a 32-bit value to 1 without memory ordering.
+ *
+ * @param nr
+ *   The target bit to set.
+ * @param addr
+ *   The address holding the bit.
+ */
+__rte_experimental
+static inline void
+rte_set_bit32_relaxed(unsigned int nr, volatile uint32_t *addr)
+{
+	RTE_ASSERT(nr < 32);
+
+	uint32_t mask = UINT32_C(1) << nr;
+	*addr = (*addr) | mask;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Clear the target bit in a 32-bit value to 0 without memory ordering.
+ *
+ * @param nr
+ *   The target bit to clear.
+ * @param addr
+ *   The address holding the bit.
+ */
+__rte_experimental
+static inline void
+rte_clear_bit32_relaxed(unsigned int nr, volatile uint32_t *addr)
+{
+	RTE_ASSERT(nr < 32);
+
+	uint32_t mask = UINT32_C(1) << nr;
+	*addr = (*addr) & (~mask);
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Return the original bit from a 32-bit value, then set it to 1 without
+ * memory ordering.
+ *
+ * @param nr
+ *   The target bit to get and set.
+ * @param addr
+ *   The address holding the bit.
+ * @return
+ *   The original bit.
+ */
+__rte_experimental
+static inline uint32_t
+rte_test_and_set_bit32_relaxed(unsigned int nr, volatile uint32_t *addr)
+{
+	RTE_ASSERT(nr < 32);
+
+	uint32_t mask = UINT32_C(1) << nr;
+	uint32_t val = *addr;
+	*addr = (*addr) | mask;
+	return val & mask;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Return the original bit from a 32-bit value, then clear it to 0 without
+ * memory ordering.
+ *
+ * @param nr
+ *   The target bit to get and clear.
+ * @param addr
+ *   The address holding the bit.
+ * @return
+ *   The original bit.
+ */
+__rte_experimental
+static inline uint32_t
+rte_test_and_clear_bit32_relaxed(unsigned int nr, volatile uint32_t *addr)
+{
+	RTE_ASSERT(nr < 32);
+
+	uint32_t mask = UINT32_C(1) << nr;
+	uint32_t val = *addr;
+	*addr = (*addr) & (~mask);
+	return val & mask;
+}
+
+/*---------------------------- 64 bit operations ----------------------------*/
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Get the target bit from a 64-bit value without memory ordering.
+ *
+ * @param nr
+ *   The target bit to get.
+ * @param addr
+ *   The address holding the bit.
+ * @return
+ *   The target bit.
+ */
+__rte_experimental
+static inline uint64_t
+rte_get_bit64_relaxed(unsigned int nr, volatile uint64_t *addr)
+{
+	RTE_ASSERT(nr < 64);
+
+	uint64_t mask = UINT64_C(1) << nr;
+	return (*addr) & mask;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Set the target bit in a 64-bit value to 1 without memory ordering.
+ *
+ * @param nr
+ *   The target bit to set.
+ * @param addr
+ *   The address holding the bit.
+ */
+__rte_experimental
+static inline void
+rte_set_bit64_relaxed(unsigned int nr, volatile uint64_t *addr)
+{
+	RTE_ASSERT(nr < 64);
+
+	uint64_t mask = UINT64_C(1) << nr;
+	(*addr) = (*addr) | mask;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Clear the target bit in a 64-bit value to 0 without memory ordering.
+ *
+ * @param nr
+ *   The target bit to clear.
+ * @param addr
+ *   The address holding the bit.
+ */
+__rte_experimental
+static inline void
+rte_clear_bit64_relaxed(unsigned int nr, volatile uint64_t *addr)
+{
+	RTE_ASSERT(nr < 64);
+
+	uint64_t mask = UINT64_C(1) << nr;
+	*addr = (*addr) & (~mask);
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Return the original bit from a 64-bit value, then set it to 1 without
+ * memory ordering.
+ *
+ * @param nr
+ *   The target bit to get and set.
+ * @param addr
+ *   The address holding the bit.
+ * @return
+ *   The original bit.
+ */
+__rte_experimental
+static inline uint64_t
+rte_test_and_set_bit64_relaxed(unsigned int nr, volatile uint64_t *addr)
+{
+	RTE_ASSERT(nr < 64);
+
+	uint64_t mask = UINT64_C(1) << nr;
+	uint64_t val = *addr;
+	*addr = (*addr) | mask;
+	return val;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Return the original bit from a 64-bit value, then clear it to 0 without
+ * memory ordering.
+ *
+ * @param nr
+ *   The target bit to get and clear.
+ * @param addr
+ *   The address holding the bit.
+ * @return
+ *   The original bit.
+ */
+__rte_experimental
+static inline uint64_t
+rte_test_and_clear_bit64_relaxed(unsigned int nr, volatile uint64_t *addr)
+{
+	RTE_ASSERT(nr < 64);
+
+	uint64_t mask = UINT64_C(1) << nr;
+	uint64_t val = *addr;
+	*addr = (*addr) & (~mask);
+	return val & mask;
+}
+
+#endif /* _RTE_PMD_BITOPS_H_ */
diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
index 2b97715a2..0862ae64c 100644
--- a/lib/librte_eal/common/meson.build
+++ b/lib/librte_eal/common/meson.build
@@ -50,9 +50,9 @@  common_objs += eal_common_arch_objs
 
 common_headers = files(
 	'include/rte_alarm.h',
+	'include/rte_bitmap.h',
 	'include/rte_branch_prediction.h',
 	'include/rte_bus.h',
-	'include/rte_bitmap.h',
 	'include/rte_class.h',
 	'include/rte_common.h',
 	'include/rte_compat.h',
@@ -78,6 +78,7 @@  common_headers = files(
 	'include/rte_pci_dev_feature_defs.h',
 	'include/rte_pci_dev_features.h',
 	'include/rte_per_lcore.h',
+	'include/rte_pmd_bitops.h',
 	'include/rte_random.h',
 	'include/rte_reciprocal.h',
 	'include/rte_service.h',