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 3DF2B568E for ; Tue, 10 Mar 2015 04:56:52 +0100 (CET) Received: from mgw.gov.kz (mx.ctsat.kz [178.89.4.95]) by mgw.gov.kz with ESMTP id t2A3umx0016268-t2A3umx1016268; Tue, 10 Mar 2015 09:56:48 +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; Tue, 10 Mar 2015 09:55:05 +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; Tue, 10 Mar 2015 09:56:49 +0600 Message-ID: <54FE6B24.1080700@sts.kz> Date: Tue, 10 Mar 2015 09:55:16 +0600 From: Yerden Zhumabekov User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thomas Monjalon , "Qiu, Michael" References: <1425561339-13300-2-git-send-email-michael.qiu@intel.com> <9902699.YtPW44peIi@xps13> <533710CFB86FA344BFBF2D6802E60286CEF549@SHSMSX101.ccr.corp.intel.com> <9442704.dXlXz1iyK3@xps13> In-Reply-To: <9442704.dXlXz1iyK3@xps13> 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 1/3 v2] librte_hash: Fix unsupported instruction `crc32' in i686 platform 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: Tue, 10 Mar 2015 03:56:52 -0000 08.03.2015 0:39, Thomas Monjalon пишет: > 2015-03-06 01:39, Qiu, Michael: >> On 3/6/2015 1:11 AM, Thomas Monjalon wrote: >>> 2015-03-06 00:55, Michael Qiu: >>>> ... skipped ... >>>> >>>> +#if defined RTE_ARCH_I686 || defined RTE_ARCH_X86_64 >>>> static inline uint32_t >>>> crc32c_sse42_u32(uint32_t data, uint32_t init_val) >>>> { >>>> @@ -373,7 +374,9 @@ crc32c_sse42_u32(uint32_t data, uint32_t init_val) >>>> : [data] "rm" (data)); >>>> return init_val; >>>> } >>>> +#endif >>> Wouldn't it be more elegant to define a stub which returns 0 in #else >>> in order to remove #ifdef below? >>> Not sure, matter of taste. >> It may be not a good idea, see rte_hash_crc_8byte(), if no crc32 >> support, it will use crc32c_2words(), if we define a stub which returns >> 0 in #else, then we need always check the return value whether it is >> none-zero otherwise need fallback. > I don't think so. > The stub won't never been called because they are protected by the cpuflag > condition. That would be a bad surprise if one tries to launch that pre-built binary on SSE4.2-capable arch :) It's fine though, if binary portability is out of scope here. -- Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ