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
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?
-----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); } > >
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.
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
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
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.
-----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 > >
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
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
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