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 66BC8592D for ; Wed, 30 Jul 2014 14:59:28 +0200 (CEST) Received: from nat-pool-rdu-t.redhat.com ([66.187.233.202] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XCTVL-00063Q-Q8; Wed, 30 Jul 2014 09:01:22 -0400 Date: Wed, 30 Jul 2014 09:01:10 -0400 From: Neil Horman To: "Ananyev, Konstantin" Message-ID: <20140730130109.GA19737@localhost.localdomain> References: <1406665466-29654-1-git-send-email-nhorman@tuxdriver.com> <2601191342CEEE43887BDE71AB97725821345777@IRSMSX105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB97725821345777@IRSMSX105.ger.corp.intel.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: Wed, 30 Jul 2014 12:59:28 -0000 On Wed, Jul 30, 2014 at 12:07:39PM +0000, Ananyev, Konstantin wrote: > > > Hi Neil, > > > Hey all- > > I've been trying to update the fedora dpdk package to support VFIO > > enabled drivers and ran into a problem in which ixgbe didn't compile because the > > rxtx_vec code uses sse4.2 instruction intrinsics, which aren't supported in the > > default config I have. I tried to remedy this by replacing the intrinsics with > > the __builtin macros, but it was pointed out (correctly), that this doesn't work > > properly. So this is my second attempt, which I actually like a bit better. I > > noted that code that uses intrinsics (ixgbe and the acl library), don't need to > > have those instructions turned on build-wide. Rather, we can just enable the > > instructions in the specific code we want to build with support for that, and > > test for instruction support dynamically at run time. This allows me to build > > the dpdk for a generic platform, but in such a way that some optimizations can > > be used if the executing cpu supports them at run time. > > Indeed it looks much better to me too. > Just few nits from me: > > 1. > @@ -112,6 +112,15 @@ rte_acl_create(const struct rte_acl_param *param) > > struct rte_acl_list *acl_list; > > struct rte_tailq_entry *te; > > char name[sizeof(ctx->name)]; > > + static int acl_supported = -1; > > + > > + if (acl_supported == -1) > > + acl_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_2); > > Do we really need acl_supported here? > It seems not a big deal to just always call rte_cpu_get_flag_enabled(). > After all it is a create function, and no-one expects it to be extremely fast. > Need, no. My only thought was that some poorly behaved application will call rte_acl_create multiple times regardless of the error returned, and doing so will cause large volumes of calls to cpuid, which evicts several high-use registers, so I didn't want to call it more than needed. If you think its ok to call it multiple times though, I'm fine with removing it. > 2. Can you add RTE_LOG(ERR, ...) for re_acl_create() and ixgbe_rx_vec_condition_check() if sse4.2 is not supported? > Absolutely, v2 shortly. Neil > Konstantin > >