Hi Stanislaw,
On 29/04/2021 21H:45, Stanislaw Kardach wrote:
On Thu, Apr 29, 2021 at 12:17:08PM +0300, Medvedkin, Vladimir wrote:
<snip>
Test Failed
RTE>>
--- stderr ---
EAL: Detected 2 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Detected shared linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/thash_autotest/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available 1048576 kB hugepages reported
EAL: VFIO support initialized
APP: HPET is not enabled, using TSC as default timer
HASH: Can't add helper due to conflict with existing helper second_range
HASH: Can't generate m-sequence due to period overflow
EAL: Test assert test_adjust_tuple line 559 failed: can not adjust
tuple, ret -17
I can see the same issue on my side. Happening randomly, more often on a
RISC-V target than on my laptop (i5-10210U). Though the reproduction
seems to be a lot of patience and the following:
meson test --repeat 100000 DPDK:fast-tests / thash_autotest
I wonder if it can be related to the desired_value in test_adjust_tuple
being a randomized value without setting the seed prior to the test?
I haven't analyzed the code in-depth but it seems that the
rte_thash_add_helper() also uses a random lfsr which is then used in the
subkey generation. Could this contribute to the randomness of the issue?
The problem here is that the rte_thash_adjust_tuple() function does not
guarantee that it will find a tuple in a given number of attempts in the
case when the fn() callback is passed. It depends on random, the logic
of the fn() callback, and the content of the userdata.
So, in the test we have:
- 96-bit("sizeof(tuple) * CHAR_BITS") tuple
- 16-bit("reta_sz * 2") changeable part of the tuple (i.e. subtuple)
- we want to have a collision in the hash value for 8("reta_sz") least
significant bits
In other words there are 16 changeable bits inside the subtuple and 8
least significant bits of them are changed by the
rte_thash_get_complement() in order to produce collision. The rest 8
bits are our entropy, i.e. 2^8 different subtuples can produce the
required collision.
in the problematic call
ret = rte_thash_adjust_tuple(ctx, h, tuple, TUPLE_SZ, desired_value,
2, cmp_tuple_eq, tuple_copy);
the original tuple is passed to be changed and the tuple_copy we got
from the previous invocation. Content of the tuple_copy previously was
derived from the original tuple applying 8 bit complement on the
subtuple part.
On the first attempt the function gets the complement and applies it to
the original tuple, tuple becomes equal to the tuple_copy. After it
calls the callback and finds that tuple is equal to the tuple_copy. Then
on the second attempt random bits are xored with 16 bit subtuple value.
If the first 8 MSBs of random are zeroes, then after applying a new
complement to the tuple it will be equal to the tuple_copy. While we
allow only 2 attempts function returns -EEXIST.
I reworked rte_thash_adjust_tuple() removing the randomness. Instead it
increments the subtuple part which is free of complementary bits.
--
Regards,
Vladimir
