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 D3C40B368 for ; Fri, 1 Aug 2014 17:17:08 +0200 (CEST) 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 1XDEbq-0006ZL-UE; Fri, 01 Aug 2014 11:19:12 -0400 Date: Fri, 1 Aug 2014 11:19:06 -0400 From: Neil Horman To: Vincent JARDIN Message-ID: <20140801151906.GE31979@hmsreliant.think-freely.org> References: <5766264.li3nkTmgY6@xps13> <20140731143228.GB20718@hmsreliant.think-freely.org> <20140731181032.GC20718@hmsreliant.think-freely.org> <20140731183631.GC6420@localhost.localdomain> <20140731195829.GG17560@tuxdriver.com> <20140731202042.GB28495@localhost.localdomain> <20140731203200.GH17560@tuxdriver.com> <53DB53E9.6040004@6wind.com> <20140801140654.GB31979@hmsreliant.think-freely.org> <53DBAAF4.4030608@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53DBAAF4.4030608@6wind.com> 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 0/2] dpdk: Allow for dynamic enablement of some isolated features 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: Fri, 01 Aug 2014 15:17:09 -0000 On Fri, Aug 01, 2014 at 04:57:56PM +0200, Vincent JARDIN wrote: > On 01/08/2014 16:06, Neil Horman wrote: > >Thats a multi year effort, and not something I'm prepared to even > >consider undertaking. > > Sorry: I am not pushing you, it was just an open comment. I do agree that it > is a multi year effort to get it down into a wide "agreed" community. DPDK > community cannot manage it. > I understand, but I still don't think it makes sense to do. The fat elf format was origionally intended to allow transparent movement bewteen major architectures. While it certainly could be used to migrate between a smaller granularity within the same arch family, it seems like a lousy tradeoff to me, especially as the fanout for variants increases. Right now I think there are at least 4 variants within the dpdk (sse3, sse4.2, avx, and avx512). Thats a 4x increase in binary size. While that might make sense for one highly optimized application, it doesn't seem like it would make sense as a general purpose utility, as the disk space / speedup tradeoff is not super great. Neil