From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgw.gov.kz (mgw.gov.kz [89.218.88.242]) by dpdk.org (Postfix) with ESMTP id 524197E75 for ; Fri, 14 Nov 2014 12:48:36 +0100 (CET) Received: from mgw.gov.kz (mx.ctsat.kz [178.89.4.95]) by mgw.gov.kz with ESMTP id sAEBwY1E020152-sAEBwY1G020152 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2014 17:58:35 +0600 Received: from EXCASHUB1.rgp.local (192.168.40.51) by EdgeForefront.rgp.local (192.168.40.59) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 14 Nov 2014 17:58:26 +0600 Received: from [192.168.35.15] (192.168.35.15) by excashub1.rgp.local (192.168.40.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 14 Nov 2014 17:58:36 +0600 Message-ID: <5465EE3F.2010404@sts.kz> Date: Fri, 14 Nov 2014 17:57:51 +0600 From: Yerden Zhumabekov User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Neil Horman References: <1409724351-23786-1-git-send-email-e_zhumabekov@sts.kz> <2916837.QJI9btJm0N@xps13> <20141114005211.GC14230@localhost.localdomain> <5465AC00.1070602@sts.kz> <20141114113327.GA19147@hmsreliant.think-freely.org> In-Reply-To: <20141114113327.GA19147@hmsreliant.think-freely.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [192.168.35.15] X-FEAS-SYSTEM-WL: e_zhumabekov@sts.kz Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/2] rewritten rte_hash_crc() call X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 11:48:36 -0000 14.11.2014 17:33, Neil Horman пишет: > On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote: >> >> Hello, >> >> A quick grep on dpdk source shows that rte_hash_crc() is used in >> librte_hash in following context: >> >> In rte_hash.c: >> /* Hash function used if none is specified */ >> #ifdef RTE_MACHINE_CPUFLAG_SSE4_2 >> #include >> #define DEFAULT_HASH_FUNC rte_hash_crc >> #else >> #include >> #define DEFAULT_HASH_FUNC rte_jhash >> #endif >> >> In rte_fbk_hash.h >> #ifdef RTE_MACHINE_CPUFLAG_SSE4_2 >> #include >> /** Default four-byte key hash function if none is specified. */ >> #define RTE_FBK_HASH_FUNC_DEFAULT·······rte_hash_crc_4byte >> #else >> #include >> #define RTE_FBK_HASH_FUNC_DEFAULT·······rte_jhash_1word >> #endif >> #endif >> >> >> I guess it covers the cpu flags check you're talking about. >> > Not really. That covers the case of applications selecting the hash function > using the DEFUALT_HASH_FUNC macro, but doesn't nothing for applications using > the function directly. Test_hash_perf is an example of this, and ostensibly > because of the behavior without SSE4.2 it defines these huge test tables twice > based on the availability of SSE4.2. It would be better if we could allow > applications to use rte_hash_crc regardless, and make the code it uses at run > time configurable. I see, then we have a problem here :) Actually, that was one of my concerns when developing these patches. I looked through the source code of libs and examples and I saw the '#ifdef..#include..#endif'-like appoach while selecting hash function was common. So I organized patches to minimize the impact on API and not to contradict this approach. If we prefer to change this approach then, I guess, we need to introduce broader changes to rte_hash library and change other code which uses it. If that's what's needed, then it'll take some time for me to rework these patches. -- Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ