[dpdk-dev] [PATCH v5 3/5] test/hash: add additional thash tests

[Medvedkin, Vladimir]

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