From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 47296592D for ; Wed, 30 Jul 2014 15:43:10 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 30 Jul 2014 06:45:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,764,1400050800"; d="scan'208";a="577687925" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 30 Jul 2014 06:44:34 -0700 Received: from irsmsx153.ger.corp.intel.com (163.33.192.75) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 30 Jul 2014 14:44:09 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.65]) by IRSMSX153.ger.corp.intel.com ([169.254.9.133]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 14:44:08 +0100 From: "Ananyev, Konstantin" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features Thread-Index: AQHPq2sr6wrrml/Wp06PWBDKBe/rKpu4g9EAgAABPwCAABsDQA== Date: Wed, 30 Jul 2014 13:44:08 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213457B8@IRSMSX105.ger.corp.intel.com> References: <1406665466-29654-1-git-send-email-nhorman@tuxdriver.com> <2601191342CEEE43887BDE71AB97725821345777@IRSMSX105.ger.corp.intel.com> <20140730130109.GA19737@localhost.localdomain> In-Reply-To: <20140730130109.GA19737@localhost.localdomain> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 13:43:10 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, July 30, 2014 2:01 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of= some isolated features >=20 > 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 suppor= ted in the > > > default config I have. I tried to remedy this by replacing the intri= nsics with > > > the __builtin macros, but it was pointed out (correctly), that this d= oesn'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 en= able the > > > instructions in the specific code we want to build with support for t= hat, 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 optimiza= tions 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 *pa= ram) > > > struct rte_acl_list *acl_list; > > > struct rte_tailq_entry *te; > > > char name[sizeof(ctx->name)]; > > > + static int acl_supported =3D -1; > > > + > > > + if (acl_supported =3D=3D -1) > > > + acl_supported =3D 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 extremel= y 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 it= s ok to > call it multiple times though, I'm fine with removing it. >>From my thought rte_acl_create() is not supposed to be called in the middl= e packet processing. It is sort of setup function. That's why I think nothing wrong would happen= even if cpuid would be called several times.=20 Again ixgbe_rx_vec_condition_check() would probably be called much more of= ten (for each ixgbe rx queue we are going to use). > > 2. Can you add RTE_LOG(ERR, ...) for re_acl_create() and ixgbe_rx_vec_c= ondition_check() if sse4.2 is not supported? > > > Absolutely, v2 shortly. > Neil >=20 > > Konstantin > > > >