From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 3ADB07E18 for ; Wed, 19 Nov 2014 12:23:57 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xr3WT-0006qI-8W; Wed, 19 Nov 2014 06:34:14 -0500 Date: Wed, 19 Nov 2014 06:34:08 -0500 From: Neil Horman To: Bruce Richardson Message-ID: <20141119113408.GA10004@hmsreliant.think-freely.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141119101614.GA6532@bricha3-MOBL3> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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: Wed, 19 Nov 2014 11:23:57 -0000 On Wed, Nov 19, 2014 at 10:16:14AM +0000, Bruce Richardson wrote: > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote: > > On Tue, Nov 18, 2014 at 05:52:27PM +0000, Bruce Richardson wrote: > > > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote: > > > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote: > > > > > > > > > > 18.11.2014 22:00, Neil Horman пишет: > > > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov wrote: > > > > > >> 18.11.2014 20:41, Neil Horman пишет: > > > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov wrote: > > > > > >>>> /** > > > > > >>>> * Use single crc32 instruction to perform a hash on a 4 byte value. > > > > > >>>> + * Fall back to software crc32 implementation in case SSE4.2 is > > > > > >>>> + * not supported > > > > > >>>> * > > > > > >>>> * @param data > > > > > >>>> * Data to perform hash on. > > > > > >>>> @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data, uint32_t init_val) > > > > > >>>> static inline uint32_t > > > > > >>>> rte_hash_crc_4byte(uint32_t data, uint32_t init_val) > > > > > >>>> { > > > > > >>>> - return _mm_crc32_u32(init_val, data); > > > > > >>>> +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2 > > > > > >>>> + if (likely(crc32_alg == CRC32_SSE42)) > > > > > >>>> + return _mm_crc32_u32(init_val, data); > > > > > >>>> +#endif > > > > > >>> you don't really need these ifdefs here anymore given that you have a > > > > > >>> constructor to do the algorithm selection. In fact you need to remove them, in > > > > > >>> the event you build on a system that doesn't support SSE42, but run on a system > > > > > >>> that does. > > > > > >> Originally, I thought so as well. I wrote the code without these ifdefs, > > > > > >> but it didn't compile on my machine which doesn't support SSE4.2. Error > > > > > >> was triggered by nmmintrin.h which has a check for respective GCC > > > > > >> extension. So I think these ifdefs are indeed required. > > > > > >> > > > > > > You need to edit the makefile so that the compiler gets passed the option > > > > > > -msse42. That way it will know to emit sse42 instructions. It will also allow > > > > > > you to remove the ifdef from the include file > > > > > > > > > > In this case, I guess there are two options: > > > > > 1) modify all makefiles which use librte_hash > > > > > 2) move all function bodies from rte_hash_crc.h to separate module, > > > > > leaving prototype definitions there only. > > > > > > > > > > Everybody's up for the second option? :) > > > > > > > > > Crud, you're right, I didn't think about the header inclusion issue. Is it > > > > worth adding the jump to enable the dynamic hash selection? > > > > Neil > > > > > > Maybe for cases where SSE4.2 is not currently available, i.e. for generic builds. > > > For builds where we have hardware support confirmed at compile time, just use > > > the function from the header file. > > > Does that make sense? > > > > > I'm not certain of that, as I don't think anything can be 'confirmed' at compile > > time. I.e. just because you have sse42 at compile time doesn't guarantee you > > have it at run time with a DSO. If you have these as macros, you need to enable > > sse42 whereever you include the file so that the intrinsic works properly. > > Well, if you compile with sse42 at compile time, the compiler is free to insert > sse4 instructions at any place it feels like, irrespective of whether or not you > use SSE4 intrinsics, so I would never expect such a DSO to work on a system > without SSE42 support. > > > > > an alternate option would be to not use the intrinsic, and craft some explicit > > __asm__ statement that executes the right sse42 instructions. That way the asm > > is directly emitted, without requiring the -msse42 flag at all, and it will just > > work in all the files that call it. > > > > I really don't like that approach. I think using intrinsics is much more > maintainable. > I grant you that using an intrinsic is easier to read, but if the code doesn't compile when using the intrinsic unless you have sse42 turned on, I'm not sure what choice we have. and inline asm isn't that hard to maintain. We're talking about three lines of code: asm( "mov %[1],%eax mov %[2],%edx crc32l %edx,%eax": [edx] "r" (crc) /*output*/ : [1] "r" (crc), /* input */ [2] "r" (val) : [eax] "r" /* clobber */ ) I don't have the syntax quite right, but its pretty easy to read the intent. Its not like we dont have precidence for this, the atomic interface and several pmds do this frequently. Neil > /Bruce > >