Re: [dpdk-dev] Minimun value of RTE_MAX_LCORE

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Oct 15, 2020 at 10:49:17AM +0000, Juraj Linkeš wrote:
> Hi dpdk devs,
> 
> Is there a constraint on how low RTE_MAX_LCORE can be? I'm implementing a
> discovery mechanism that sets RTE_MAX_LCORE according to the number of
> host cores, but I'm hitting errors when the values are low:
> https://travis-ci.com/github/jlinkes/dpdk/jobs/399596828 Message: Found 2
> cores Message: Found 1 numa nodes
> 
> ../app/test/test_rcu_qsbr.c:296:54: error: iteration 2 invokes undefined
> behavior [-Werror=aggressive-loop-optimizations]
> 
> ../app/test/test_rcu_qsbr.c:315:55: error: array subscript is above array
> bounds [-Werror=array-bounds]
> 
> All VM jobs failed in that Travis build. Travis VMs only have 2 cores, so
> I tried to put a bound on the build. I set it to 4 and all jobs except
> GCC shared lib jobs passed, which still threw iteration 4 invokes
> undefined behavior error:
> https://travis-ci.com/github/jlinkes/dpdk/jobs/400004089
> 
> ../examples/performance-thread/l3fwd-thread/main.c:2338:34: error:
> iteration 4 invokes undefined behavior
> [-Werror=aggressive-loop-optimizations]
> 
> This happens for number of cores < 32 and looks like a limitation unique
> to l3fwd (with cores between 4 and 32 - I didn't see the error
> elsewhere).
> 
> Should I use the bound or are these legitimate errors? The fact that only
> GCC (and not clang) shared lib jobs failed is also suspicious.
>
Four seems a reasonable lower bound to have, but 32 seems high. I agree
that the warning itself looks suspicious too.

However, looking at the code and the line in question, I think there is
indeed an app bug.  The loop goes up to MAX_ETHPORTS, but the tx_bufs array
being dereferenced is dimensioned by MAX_LCORES, which is why you hit
problems with lcore values below 32 (==MAX_ETHPORTS). Based on the use, I
suspect the structure definition may be wrong and the array should be
dimensioned for MAX_ETHPORTS - but I haven't dug into the code further than
that.

Regards,
/Bruce