Was looking at where rte_rand() is currently used in DPDK.
Found that rte_pie uses it (that is expected.
But it also using it wrong on a couple of levels.
First. Look at:
#define RTE_RAND_MAX ~0LLU /**< Max value of the random number */
_rte_pie_drop(const struct rte_pie_config *pie_cfg,
struct rte_pie *pie)
{
uint64_t rand_value;
...
rand_value = rte_rand()/RTE_RAND_MAX;
if ((double)rand_value < pie->drop_prob) {
pie->accu_prob = 0;
return 1;
}
/* No drop */
return 0;
Since rand_value is 64 bit unsigned value the division happens as unsigned
Therefore for all values of rte_rand(). rand_value is going to be 0
Converting it to double just makes it zero in another form.
How was PIE tested? Why was this not seen.
Second, the obvious fix would be to make rand_value a double.
But doing floating point divide in the packet path would be a major
performance loss. Saw this earlier with the packet_sched code.
