From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A5007A0562; Tue, 4 May 2021 16:06:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6120C40147; Tue, 4 May 2021 16:06:25 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id B4C0440141 for ; Tue, 4 May 2021 16:06:23 +0200 (CEST) IronPort-SDR: krEF8TD+Of5dyiYJYJBfQr6l5Ru7CxPEw+GIra95cisBUZ8AMWE25Ha0ju3ZzIFvgK20BHv3zE ap5BK2sa/Alw== X-IronPort-AV: E=McAfee;i="6200,9189,9974"; a="185120360" X-IronPort-AV: E=Sophos;i="5.82,272,1613462400"; d="scan'208";a="185120360" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2021 07:06:14 -0700 IronPort-SDR: RieHqI8IdxTBt08jZMEmihW55SPd8meLoy0Oiy14KWKCTwiCXZEGdVIYCTdYZ2C//9ISFItPcH qqro5LizXrzw== X-IronPort-AV: E=Sophos;i="5.82,272,1613462400"; d="scan'208";a="539189635" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.215.166.178]) ([10.215.166.178]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2021 07:06:07 -0700 From: "Medvedkin, Vladimir" To: Stanislaw Kardach Cc: David Marchand , dev , "Ananyev, Konstantin" , "Chilikin, Andrey" , "Kinsella, Ray" , "Wang, Yipeng1" , "Gobriel, Sameh" , Bruce Richardson References: <1618319973-391016-1-git-send-email-vladimir.medvedkin@intel.com> <1618847995-91229-1-git-send-email-vladimir.medvedkin@intel.com> <1618847995-91229-4-git-send-email-vladimir.medvedkin@intel.com> <381c0806-877c-fe06-4a69-8f9fc8221b2c@intel.com> <20210429184508.3set2zxt5jv5b73z@toster> Message-ID: <2a7ee461-f302-7b23-e0f3-a16f3ae6e8e5@intel.com> Date: Tue, 4 May 2021 17:06:00 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210429184508.3set2zxt5jv5b73z@toster> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 3/5] test/hash: add additional thash tests X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Stanislaw, On 29/04/2021 21H:45, Stanislaw Kardach wrote: > On Thu, Apr 29, 2021 at 12:17:08PM +0300, Medvedkin, Vladimir wrote: > >>> 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