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 93E7158D9 for ; Thu, 20 Nov 2014 03:54:30 +0100 (CET) Received: from mgw.gov.kz (mx.ctsat.kz [178.89.4.95]) by mgw.gov.kz with ESMTP id sAK34urh010231-sAK34urj010231 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Nov 2014 09:04:56 +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; Thu, 20 Nov 2014 09:04:44 +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; Thu, 20 Nov 2014 09:04:57 +0600 Message-ID: <546D5A4B.8030803@sts.kz> Date: Thu, 20 Nov 2014 09:04:43 +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: <20141118144138.GB32375@hmsreliant.think-freely.org> <546B607B.9030808@sts.kz> <20141118160005.GC32375@hmsreliant.think-freely.org> <546B7E2D.7050705@sts.kz> <20141118174619.GE32375@hmsreliant.think-freely.org> <20141118175226.GC5840@bricha3-MOBL3> <20141118213624.GF32375@hmsreliant.think-freely.org> <20141119101614.GA6532@bricha3-MOBL3> <546C8097.6000509@sts.kz> <20141119150725.GB28013@localhost.localdomain> In-Reply-To: <20141119150725.GB28013@localhost.localdomain> 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 v4 3/5] hash: add fallback to software CRC32 implementation 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: Thu, 20 Nov 2014 02:54:31 -0000 19.11.2014 21:07, Neil Horman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Wed, Nov 19, 2014 at 05:35:51PM +0600, Yerden Zhumabekov wrote: >> static inline uint32_t >> crc32_sse42_u32(uint32_t data, uint32_t init_val) >> { >> /*=C2=B7=C2=B7__asm__ volatile( >> =C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7= "crc32l %[data], %[init_val];" >> =C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7= : [init_val] "+r" (init_val) >> =C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7= : [data] "rm" (data)); >> =C2=B7=C2=B7=C2=B7=C2=B7return init_val;*/ >> >> But wait, will __builtin_ia32_crc32si and __builtin_ia32_crc32di >> functions do the trick? ICC has them? > If builtins work on both icc and gcc, yes, that would be a solution as = it > creates non sse instructions when the target cpu doesn't support it. Can anyone acknowledge? > >> What about prototyping functions and extracting their bodies to separa= te >> module? Does it break anything? >> > That would be a variant on the asm inline idea, but yes, I think that w= ould work > too No luck. Performance degrades up to 30-50 percent if extracting functions to separate module. --=20 Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ