On Fri, Jun 28, 2019 at 2:57 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote:
> On 6/15/2019 7:42 AM, David Marchand wrote:
> > We can have up to RTE_MAX_LCORE in a dpdk application.
> > Remove the limit on 128 cores and tests that are now always false.
> >
> > Fixes: b87089b0bb19 ("test/rcu: add API and functional tests")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand <david.march...@redhat.com>
>
> <...>
>
> > @@ -664,12 +643,12 @@ static struct rte_hash *init_hash(void)
> > goto test_fail;
> >
> > /* Make sure the actual number of cores provided is less than
> > - * TEST_RCU_MAX_LCORE. This will allow for some threads not
> > + * RTE_MAX_LCORE. This will allow for some threads not
> > * to be registered on the QS variable.
> > */
> > - if (num_cores >= TEST_RCU_MAX_LCORE) {
> > + if (num_cores >= RTE_MAX_LCORE) {
> > printf("Test failed! number of cores provided should be
> less than %d\n",
> > - TEST_RCU_MAX_LCORE);
> > + RTE_MAX_LCORE);
> > goto test_fail;
> > }
> >
> >
>
> Hi David,
>
> This is causing build error for arm [1] since in config they have
> "CONFIG_RTE_MAX_LCORE=256"
> Can we make 'num_cores' 'uint16_t'?
>
> [1]
> .../dpdk/app/test/test_rcu_qsbr_perf.c:649:16: error: comparison is always
> false
> due to limited range of data type [-Werror=type-limits]
> if (num_cores >= RTE_MAX_LCORE) {
> ^~
>
I checked and I am not reproducing it in travis arm64 compilation, but did
not investigate why.
Indeed there is an issue, I can send a patch to fix, but Honnappa also
reported it and sent a patch [1].
1: http://patchwork.dpdk.org/patch/55530/
--
David Marchand
