From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) by dpdk.org (Postfix) with ESMTP id A546D1F5 for ; Wed, 28 Jan 2015 22:48:13 +0100 (CET) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id D153675170E43; Wed, 28 Jan 2015 21:48:08 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0SLmAxC027730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jan 2015 16:48:10 -0500 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.168]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 16:48:10 -0500 From: "EDMISON, Kelvin (Kelvin)" To: "Wang, Zhihong" , Stephen Hemminger , Neil Horman Thread-Topic: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization Thread-Index: AQHQM4rGk4ri2m//y0+DvAHJ/c2EFJzHvQ6AgADqhQCAAMvXAIAAEcSAgADApYCAAJS5gIAABzsAgAAFRICAAAFgAIAAayOAgAAR9QCAARPvAIAHh/0AgAIfrQA= Date: Wed, 28 Jan 2015 21:48:09 +0000 Message-ID: References: <20150119130221.GB21790@hmsreliant.think-freely.org> <20150120151118.GD18449@hmsreliant.think-freely.org> <20150120161453.GA5316@bricha3-MOBL3> <54BF9D59.7070104@bisdn.de> <20150121130234.GB10756@bricha3-MOBL3> <54BFA7D5.7020106@bisdn.de> <20150121132620.GC10756@bricha3-MOBL3> <20150121114947.0753ae87@urahara> <20150121205404.GB32617@hmsreliant.think-freely.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization 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, 28 Jan 2015 21:48:13 -0000 On 2015-01-27, 3:22 AM, "Wang, Zhihong" wrote: > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of EDMISON, Kelvin >> (Kelvin) >> Sent: Friday, January 23, 2015 2:22 AM >> To: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization >>=20 >>=20 >>=20 >> On 2015-01-21, 3:54 PM, "Neil Horman" wrote: >>=20 >> >On Wed, Jan 21, 2015 at 11:49:47AM -0800, Stephen Hemminger wrote: >> >> On Wed, 21 Jan 2015 13:26:20 +0000 >> >> Bruce Richardson wrote: >> >> [..trim...] >> >> One issue I have is that as a vendor we need to ship on binary, not >> >>different distributions >> >> for each Intel chip variant. There is some support for multi-chip >> >>version functions >> >> but only in latest Gcc which isn't in Debian stable. And the >>multi-chip >> >>version >> >> of functions is going to be more expensive than inlining. For some >> >>cases, I have >> >> seen that the overhead of fancy instructions looks good but have >>nasty >> >>side effects >> >> like CPU stall and/or increased power consumption which turns of >>turbo >> >>boost. >> >> >> >> >> >> Distro's in general have the same problem with special case >> >>optimizations. >> >> >> >What we really need is to do something like borrow the alternatives >> >mechanism >> >from the kernel so that we can dynamically replace instructions at run >> >time >> >based on cpu flags. That way we could make the choice at run time, and >> >wouldn't >> >have to do alot of special case jumping about. >> >Neil >>=20 >> +1. >>=20 >> I think it should be an anti-requirement that the build machine be the >> exact same chip as the deployment platform. >>=20 >> I like the cpu flag inspection approach. It would help in the case >>where >> DPDK is in a VM and an odd set of CPU flags have been exposed. >>=20 >> If that approach doesn't work though, then perhaps DPDK memcpy could go >> through a benchmarking at app startup time and select the most >>performant >> option out of a set, like mdraid's raid6 implementation does. To give >>an >> example, this is what my systems print out at boot time re: raid6 >> algorithm selection. >> raid6: sse2x1 3171 MB/s >> raid6: sse2x2 3925 MB/s >> raid6: sse2x4 4523 MB/s >> raid6: using algorithm sse2x4 (4523 MB/s) >>=20 >> Regards, >> Kelvin >>=20 > >Thanks for the proposal! > >For DPDK, performance is always the most important concern. We need to >utilize new architecture features to achieve that, so solution per arch >is necessary. >Even a few extra cycles can lead to bad performance if they're in a hot >loop. >For instance, let's assume DPDK takes 60 cycles to process a packet on >average, then 3 more cycles here means 5% performance drop. > >The dynamic solution is doable but with performance penalties, even if it >could be small. Also it may bring extra complexity, which can lead to >unpredictable behaviors and side effects. >For example, the dynamic solution won't have inline unrolling, which can >bring significant performance benefit for small copies with constant >length, like eth_addr. > >We can investigate the VM scenario more. > >Zhihong (John) John, Thanks for taking the time to answer my newbie question. I deeply appreciate the attention paid to performance in DPDK. I have a follow-up though. I'm trying to figure out what requirements this approach creates for the software build environment. If we want to build optimized versions for Haswell, Ivy Bridge, Sandy Bridge, etc, does this mean that we must have one of each micro-architecture available for running the builds, or is there a way of cross-compiling for all micro-architectures from just one build environment? Thanks, Kelvin=20