[dpdk-dev] [PATCH] eal: fix build issue

[dpdk-dev] [PATCH] eal: fix build issue

[Jerin Jacob]

Some toolchain has fls() definition in string.h as argument type int,
which is conflicting uint32_t argument type.

/export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19:
error: conflicting types for ‘fls’
 static inline int fls(uint32_t x)
                  ^~~

/opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
note: previous declaration of ‘fls’ was here
 int  fls(int) __pure2;

FreeBSD string.h also has fls() with argument as int type.
https://www.freebsd.org/cgi/man.cgi?query=fls&sektion=3

Fixing the conflict by renaming internal function as __fls

Fixes: ffe3ec811ef5 ("sched: introduce reciprocal divide")
Cc: stable@dpdk.org

Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
 lib/librte_eal/common/rte_reciprocal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/rte_reciprocal.c b/lib/librte_eal/common/rte_reciprocal.c
index d81b11db6..f2c7453d2 100644
--- a/lib/librte_eal/common/rte_reciprocal.c
+++ b/lib/librte_eal/common/rte_reciprocal.c
@@ -44,7 +44,7 @@
 /* find largest set bit.
  * portable and slow but does not matter for this usage.
  */
-static inline int fls(uint32_t x)
+static inline int __fls(uint32_t x)
 {
 	int b;
 
@@ -62,7 +62,7 @@ struct rte_reciprocal rte_reciprocal_value(uint32_t d)
 	uint64_t m;
 	int l;
 
-	l = fls(d - 1);
+	l = __fls(d - 1);
 	m = ((1ULL << 32) * ((1ULL << l) - d));
 	m /= d;
 
-- 
2.19.1

Re: [dpdk-dev] [PATCH] eal: fix build issue

[Thomas Monjalon]

06/11/2018 12:45, Jerin Jacob:
> Some toolchain has fls() definition in string.h as argument type int,
> which is conflicting uint32_t argument type.
> 
> /export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19:
> error: conflicting types for ‘fls’
>  static inline int fls(uint32_t x)
>                   ^~~
> 
> /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
> note: previous declaration of ‘fls’ was here
>  int  fls(int) __pure2;
> 
> FreeBSD string.h also has fls() with argument as int type.
> https://www.freebsd.org/cgi/man.cgi?query=fls&sektion=3
> 
> Fixing the conflict by renaming internal function as __fls

Why not rte_fls? Would it be more future proof?

Re: [dpdk-dev] [PATCH] eal: fix build issue

[Jerin Jacob]

-----Original Message-----
> Date: Tue, 06 Nov 2018 13:29:19 +0100
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: "dev@dpdk.org" <dev@dpdk.org>, "Jacob, Jerin"
>  <Jerin.JacobKollanukkaran@cavium.com>, "stable@dpdk.org" <stable@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH] eal: fix build issue
> 
> 
> 06/11/2018 12:45, Jerin Jacob:
> > Some toolchain has fls() definition in string.h as argument type int,
> > which is conflicting uint32_t argument type.
> >
> > /export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19:
> > error: conflicting types for ‘fls’
> >  static inline int fls(uint32_t x)
> >                   ^~~
> >
> > /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
> > note: previous declaration of ‘fls’ was here
> >  int  fls(int) __pure2;
> >
> > FreeBSD string.h also has fls() with argument as int type.
> > https://www.freebsd.org/cgi/man.cgi?query=fls&sektion=3
> >
> > Fixing the conflict by renaming internal function as __fls
> 
> Why not rte_fls? Would it be more future proof?

Agreed. There are two instance of fls in dpdk code base now,

1) lib/librte_eal/common/rte_reciprocal.c takes uint32_t
2) drivers/net/fm10k/fm10k_ethdev.c has macro, used with uint16_t as
argument.

Should we make it as macro or follow libc prototype where argument is
int.

Something like below,

static inline int
rte_fls(int x)
{
	return (x == 0) ? 0 : sizeof(x) * 8 - __builtin_clz(x);
}


 

> 
> 

Re: [dpdk-dev] [PATCH] eal: fix build issue

[Thomas Monjalon]

06/11/2018 14:31, Jerin Jacob:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 06/11/2018 12:45, Jerin Jacob:
> > > Some toolchain has fls() definition in string.h as argument type int,
> > > which is conflicting uint32_t argument type.
> > >
> > > /export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19:
> > > error: conflicting types for ‘fls’
> > >  static inline int fls(uint32_t x)
> > >                   ^~~
> > >
> > > /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
> > > note: previous declaration of ‘fls’ was here
> > >  int  fls(int) __pure2;
> > >
> > > FreeBSD string.h also has fls() with argument as int type.
> > > https://www.freebsd.org/cgi/man.cgi?query=fls&sektion=3
> > >
> > > Fixing the conflict by renaming internal function as __fls
> > 
> > Why not rte_fls? Would it be more future proof?
> 
> Agreed. There are two instance of fls in dpdk code base now,
> 
> 1) lib/librte_eal/common/rte_reciprocal.c takes uint32_t
> 2) drivers/net/fm10k/fm10k_ethdev.c has macro, used with uint16_t as
> argument.
> 
> Should we make it as macro or follow libc prototype where argument is
> int.
> 
> Something like below,
> 
> static inline int
> rte_fls(int x)
> {
> 	return (x == 0) ? 0 : sizeof(x) * 8 - __builtin_clz(x);
> }

I tend to think that using uint32_t parameter would be more useful in DPDK.

[dpdk-dev] [PATCH v2 1/2] eal: introduce rte version of fls

[Jerin Jacob]

The function returns the last (most-significant) bit set.
Added unit testcase to verify rte_fls_u32().

Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
v2:
- Introduce rte_fls_u32()
---
 lib/librte_eal/common/include/rte_common.h | 19 +++++++++++++
 test/test/test_common.c                    | 32 ++++++++++++++++++++++
 2 files changed, 51 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index cba7bbc1d..87f0f6302 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -473,6 +473,25 @@ rte_log2_u32(uint32_t v)
 	return rte_bsf32(v);
 }
 
+
+/**
+ * Return the last (most-significant) bit set.
+ *
+ * @note The last (most significant) bit is at position 32.
+ * @note rte_fls_u32(0) = 0, rte_fls_u32(1) = 1, rte_fls_u32(0x80000000) = 32
+ *
+ * @param x
+ *     The input parameter.
+ * @return
+ *     The last (most-significant) bit set, or 0 if the input is 0.
+ */
+static inline int
+rte_fls_u32(uint32_t x)
+{
+	return (x == 0) ? 0 : 32 - __builtin_clz(x);
+}
+
+
 #ifndef offsetof
 /** Return the offset of a field in a structure. */
 #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
diff --git a/test/test/test_common.c b/test/test/test_common.c
index 7a67e458e..c6d17baae 100644
--- a/test/test/test_common.c
+++ b/test/test/test_common.c
@@ -188,6 +188,37 @@ test_log2(void)
 	return 0;
 }
 
+static int
+test_fls(void)
+{
+	struct fls_test_vector {
+		uint32_t arg;
+		int rc;
+	};
+	int expected, rc;
+	uint32_t i, arg;
+
+	const struct fls_test_vector test[] = {
+		{0x0, 0},
+		{0x1, 1},
+		{0x4000, 15},
+		{0x80000000, 32},
+	};
+
+	for (i = 0; i < RTE_DIM(test); i++) {
+		arg = test[i].arg;
+		rc = rte_fls_u32(arg);
+		expected = test[i].rc;
+		if (rc != expected) {
+			printf("Wrong rte_fls_u32(0x%x) rc=%d, expected=%d\n",
+				arg, rc, expected);
+			return TEST_FAILED;
+		}
+	}
+
+	return 0;
+}
+
 static int
 test_common(void)
 {
@@ -196,6 +227,7 @@ test_common(void)
 	ret |= test_macros(0);
 	ret |= test_misc();
 	ret |= test_log2();
+	ret |= test_fls();
 
 	return ret;
 }
-- 
2.19.1

[dpdk-dev] [PATCH v2 2/2] eal: fix build issue

[Jerin Jacob]

Some toolchain has fls() definition in string.h as argument type int,
which is conflicting uint32_t argument type.

/export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19:
error: conflicting types for ‘fls’
 static inline int fls(uint32_t x)
                  ^~~

/opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
note: previous declaration of ‘fls’ was here
 int  fls(int) __pure2;

FreeBSD string.h also has fls() with argument as int type.
https://www.freebsd.org/cgi/man.cgi?query=fls&sektion=3

Fixing the conflict by using rte version of fls.

Fixes: ffe3ec811ef5 ("sched: introduce reciprocal divide")
Fixes: faf2b25c9f80 ("fm10k: support VMDQ in multi-queue configuration")
Cc: stable@dpdk.org

Suggested-by: Thomas Monjalon <thomas@monjalon.net>
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
v2:
- Introduce and use rte version of fls(Thomas Monjalon)
---
 drivers/net/fm10k/fm10k_ethdev.c       | 11 +++--------
 lib/librte_eal/common/rte_reciprocal.c | 17 +----------------
 2 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index c852022dd..85fb6c5cb 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -464,11 +464,6 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 	return 0;
 }
 
-/* fls = find last set bit = 32 minus the number of leading zeros */
-#ifndef fls
-#define fls(x) (((x) == 0) ? 0 : (32 - __builtin_clz((x))))
-#endif
-
 static void
 fm10k_dev_vmdq_rx_configure(struct rte_eth_dev *dev)
 {
@@ -1030,8 +1025,8 @@ fm10k_dev_dglort_map_configure(struct rte_eth_dev *dev)
 
 	macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
 	nb_queue_pools = macvlan->nb_queue_pools;
-	pool_len = nb_queue_pools ? fls(nb_queue_pools - 1) : 0;
-	rss_len = fls(dev->data->nb_rx_queues - 1) - pool_len;
+	pool_len = nb_queue_pools ? rte_fls_u32(nb_queue_pools - 1) : 0;
+	rss_len = rte_fls_u32(dev->data->nb_rx_queues - 1) - pool_len;
 
 	/* GLORT 0x0-0x3F are used by PF and VMDQ,  0x40-0x7F used by FD */
 	dglortdec = (rss_len << FM10K_DGLORTDEC_RSSLENGTH_SHIFT) | pool_len;
@@ -1042,7 +1037,7 @@ fm10k_dev_dglort_map_configure(struct rte_eth_dev *dev)
 	FM10K_WRITE_REG(hw, FM10K_DGLORTDEC(0), dglortdec);
 
 	/* Flow Director configurations, only queue number is valid. */
-	dglortdec = fls(dev->data->nb_rx_queues - 1);
+	dglortdec = rte_fls_u32(dev->data->nb_rx_queues - 1);
 	dglortmask = (GLORT_FD_MASK << FM10K_DGLORTMAP_MASK_SHIFT) |
 			(hw->mac.dglort_map + GLORT_FD_Q_BASE);
 	FM10K_WRITE_REG(hw, FM10K_DGLORTMAP(1), dglortmask);
diff --git a/lib/librte_eal/common/rte_reciprocal.c b/lib/librte_eal/common/rte_reciprocal.c
index d81b11db6..f017d0c28 100644
--- a/lib/librte_eal/common/rte_reciprocal.c
+++ b/lib/librte_eal/common/rte_reciprocal.c
@@ -41,28 +41,13 @@
 
 #include "rte_reciprocal.h"
 
-/* find largest set bit.
- * portable and slow but does not matter for this usage.
- */
-static inline int fls(uint32_t x)
-{
-	int b;
-
-	for (b = 31; b >= 0; --b) {
-		if (x & (1u << b))
-			return b + 1;
-	}
-
-	return 0;
-}
-
 struct rte_reciprocal rte_reciprocal_value(uint32_t d)
 {
 	struct rte_reciprocal R;
 	uint64_t m;
 	int l;
 
-	l = fls(d - 1);
+	l = rte_fls_u32(d - 1);
 	m = ((1ULL << 32) * ((1ULL << l) - d));
 	m /= d;
 
-- 
2.19.1

Re: [dpdk-dev] [dpdk-stable] [PATCH v2 2/2] eal: fix build issue

[Thomas Monjalon]

07/11/2018 07:59, Jerin Jacob:
>  drivers/net/fm10k/fm10k_ethdev.c       | 11 +++--------
>  lib/librte_eal/common/rte_reciprocal.c | 17 +----------------
>  2 files changed, 4 insertions(+), 24 deletions(-)

This patch is corrupted, please check.

Re: [dpdk-dev] [dpdk-stable] [PATCH v2 2/2] eal: fix build issue

[Jerin Jacob]

-----Original Message-----
> Date: Mon, 12 Nov 2018 02:37:15 +0100
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: stable@dpdk.org, "dev@dpdk.org" <dev@dpdk.org>, Qi Zhang
>  <qi.z.zhang@intel.com>, Xiao Wang <xiao.w.wang@intel.com>,
>  "sthemmin@microsoft.com" <sthemmin@microsoft.com>, "shaopeng.he@intel.com"
>  <shaopeng.he@intel.com>, "Jacob, Jerin"
>  <Jerin.JacobKollanukkaran@cavium.com>
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2 2/2] eal: fix build issue
> 
> 
> 07/11/2018 07:59, Jerin Jacob:
> >  drivers/net/fm10k/fm10k_ethdev.c       | 11 +++--------
> >  lib/librte_eal/common/rte_reciprocal.c | 17 +----------------
> >  2 files changed, 4 insertions(+), 24 deletions(-)
> 
> This patch is corrupted, please check.

Looks like it is working, can you check from patchwork.

➜ [j] $ pwclient get 47915
Saved patch to v2-1-2-eal-introduce-rte-version-of-fls
➜ [j] $ pwclient get 47916
Saved patch to v2-2-2-eal-fix-build-issue

➜ [master][dpdk.org] $ git am -3 /tmp/j/v2-*
Applying: eal: introduce rte version of fls
Applying: eal: fix build issue

➜ [master]laptop [dpdk.org] $ echo $?
0


> 
> 

Re: [dpdk-dev] [dpdk-stable] [PATCH v2 2/2] eal: fix build issue

[Ferruh Yigit]

On 11/12/2018 4:50 AM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Mon, 12 Nov 2018 02:37:15 +0100
>> From: Thomas Monjalon <thomas@monjalon.net>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>> Cc: stable@dpdk.org, "dev@dpdk.org" <dev@dpdk.org>, Qi Zhang
>>  <qi.z.zhang@intel.com>, Xiao Wang <xiao.w.wang@intel.com>,
>>  "sthemmin@microsoft.com" <sthemmin@microsoft.com>, "shaopeng.he@intel.com"
>>  <shaopeng.he@intel.com>, "Jacob, Jerin"
>>  <Jerin.JacobKollanukkaran@cavium.com>
>> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2 2/2] eal: fix build issue
>>
>>
>> 07/11/2018 07:59, Jerin Jacob:
>>>  drivers/net/fm10k/fm10k_ethdev.c       | 11 +++--------
>>>  lib/librte_eal/common/rte_reciprocal.c | 17 +----------------
>>>  2 files changed, 4 insertions(+), 24 deletions(-)
>>
>> This patch is corrupted, please check.
> 
> Looks like it is working, can you check from patchwork.
> 
> ➜ [j] $ pwclient get 47915
> Saved patch to v2-1-2-eal-introduce-rte-version-of-fls
> ➜ [j] $ pwclient get 47916
> Saved patch to v2-2-2-eal-fix-build-issue
> 
> ➜ [master][dpdk.org] $ git am -3 /tmp/j/v2-*
> Applying: eal: introduce rte version of fls
> Applying: eal: fix build issue
> 
> ➜ [master]laptop [dpdk.org] $ echo $?
> 0

Also works for me:
$ git-pw series apply 2306

Re: [dpdk-dev] [dpdk-stable] [PATCH v2 2/2] eal: fix build issue

[Thomas Monjalon]

12/11/2018 10:01, Ferruh Yigit:
> On 11/12/2018 4:50 AM, Jerin Jacob wrote:
> > -----Original Message-----
> >> Date: Mon, 12 Nov 2018 02:37:15 +0100
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >> Cc: stable@dpdk.org, "dev@dpdk.org" <dev@dpdk.org>, Qi Zhang
> >>  <qi.z.zhang@intel.com>, Xiao Wang <xiao.w.wang@intel.com>,
> >>  "sthemmin@microsoft.com" <sthemmin@microsoft.com>, "shaopeng.he@intel.com"
> >>  <shaopeng.he@intel.com>, "Jacob, Jerin"
> >>  <Jerin.JacobKollanukkaran@cavium.com>
> >> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2 2/2] eal: fix build issue
> >>
> >>
> >> 07/11/2018 07:59, Jerin Jacob:
> >>>  drivers/net/fm10k/fm10k_ethdev.c       | 11 +++--------
> >>>  lib/librte_eal/common/rte_reciprocal.c | 17 +----------------
> >>>  2 files changed, 4 insertions(+), 24 deletions(-)
> >>
> >> This patch is corrupted, please check.
> > 
> > Looks like it is working, can you check from patchwork.
> > 
> > ➜ [j] $ pwclient get 47915
> > Saved patch to v2-1-2-eal-introduce-rte-version-of-fls
> > ➜ [j] $ pwclient get 47916
> > Saved patch to v2-2-2-eal-fix-build-issue
> > 
> > ➜ [master][dpdk.org] $ git am -3 /tmp/j/v2-*
> > Applying: eal: introduce rte version of fls
> > Applying: eal: fix build issue
> > 
> > ➜ [master]laptop [dpdk.org] $ echo $?
> > 0
> 
> Also works for me:
> $ git-pw series apply 2306

Works for me too :)

The issue I was raising is about the format of the email.
Patch 1 content encoding is quoted-printable and patch 2 is base64.

I think we should all set sendemail.transferEncoding = 8bit

Re: [dpdk-dev] [dpdk-stable] [PATCH v2 2/2] eal: fix build issue

[Thomas Monjalon]

07/11/2018 07:59, Jerin Jacob:
> Some toolchain has fls() definition in string.h as argument type int,
> which is conflicting uint32_t argument type.
> 
> /export/dpdk.org/lib/librte_eal/common/rte_reciprocal.c:47:19:
> error: conflicting types for ‘fls’
>  static inline int fls(uint32_t x)
>                   ^~~
> 
> /opt/marvell-tools-201/aarch64-marvell-elf/include/strings.h:59:6:
> note: previous declaration of ‘fls’ was here
>  int  fls(int) __pure2;
> 
> FreeBSD string.h also has fls() with argument as int type.
> https://www.freebsd.org/cgi/man.cgi?query=fls&sektion=3
> 
> Fixing the conflict by using rte version of fls.
> 
> Fixes: ffe3ec811ef5 ("sched: introduce reciprocal divide")
> Fixes: faf2b25c9f80 ("fm10k: support VMDQ in multi-queue configuration")
> Cc: stable@dpdk.org
> 
> Suggested-by: Thomas Monjalon <thomas@monjalon.net>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>

Series applied, thanks