[v7,1/6] lib/eal: implement the family of PMD bit operation APIs
Checks
Commit Message
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
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.
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?
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.
>
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.
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/
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"?
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.
>
>
>
>
> -----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.
>
> >
> >
> >
> >
@@ -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
@@ -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):
@@ -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)
@@ -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
new file mode 100644
@@ -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_ */
@@ -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',