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 23DFB7F61 for ; Sat, 15 Nov 2014 22:36:11 +0100 (CET) Received: from mgw.gov.kz (mx.ctsat.kz [178.89.4.95]) by mgw.gov.kz with ESMTP id sAFLkGXm000738-sAFLkGXo000738 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Nov 2014 03:46:16 +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; Sun, 16 Nov 2014 03:46:06 +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; Sun, 16 Nov 2014 03:46:06 +0600 Message-ID: <5467C971.7090906@sts.kz> Date: Sun, 16 Nov 2014 03:45:21 +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> <5465EE3F.2010404@sts.kz> <20141114135308.GD19147@hmsreliant.think-freely.org> <5466313B.6040407@sts.kz> <20141114184157.GF19147@hmsreliant.think-freely.org> In-Reply-To: <20141114184157.GF19147@hmsreliant.think-freely.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: Sat, 15 Nov 2014 21:36:11 -0000 15.11.2014 0:41, Neil Horman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Fri, Nov 14, 2014 at 10:43:39PM +0600, Yerden Zhumabekov wrote: >> 14.11.2014 19:53, Neil Horman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> >>> Well, its possible you'll get lucky. crc is such a common operation,= its >>> entirely possible that the gcc intrinsic emits software based crc com= putation if >>> the SSE4.2 instructions aren't enabled. I recommend modifying the te= st_hash_crc >>> function to use rte_hash_crc with SSE4.2 disabled, and see if you get= a crash. >>> If you don't examine the disassembly of your new function and confirm= that >>> something reasonable that doesn't use SSE4.2 is emitted. If thats th= e case, >>> your patch is fine, and we can focus on how to change the ifdefs in t= he existing >>> code, as use of the rte_hash_crc functions should be safe. >>> >> Unfortunately, it seems not to be the case. Trying to force compiling = a >> test program with _mm_crc32_u32 intrinsic on computer with no SSE4.2 >> support leads to "Illegal instruction error". So it looks like GCC doe= s >> not fall back to crc32 software implementation. >> > Ok, but crc32 is pretty easy to implement in software. Just appropriat= e the > calculate_crc32c function from the BSD or Linux kernels and if > (unlikely(!support_sse42)) calculate_crc32 operation. > I've almost reworked patches, but there's one more issue I was wondering about. If we use a flag (say, 'sse42_flag ') to determine code path, where should it be defined? Should it be some sort of rte_hash_crc_init() call in the init stage of application? Alternatively, I could have implemented it like this: static uint8_t sse42_flag =3D FLAG_UNKNOWN; =2E... rte_hash_crc_4byte(uint32_t data, uint32_t init_val) { if (unlikely(sse42_flag =3D=3D FLAG_UNKNOWN)) sse42_flag =3D rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_2) ? FLAG_SUPPORTED : FLAG_NOTSUPPORTED; if (likely(sse42_flag =3D=3D FLAG_SUPPORTED)) return _mm_crc32_u32(init_val, data); ..... } --=20 Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ