From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C2BD0592D for ; Wed, 30 Jul 2014 14:07:45 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 30 Jul 2014 05:03:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,763,1400050800"; d="scan'208";a="551245022" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 30 Jul 2014 05:09:28 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.65]) by IRSMSX101.ger.corp.intel.com ([169.254.1.13]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 13:07:39 +0100 From: "Ananyev, Konstantin" To: Neil Horman , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features Thread-Index: AQHPq2sr6wrrml/Wp06PWBDKBe/rKpu4g9EA Date: Wed, 30 Jul 2014 12:07:39 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725821345777@IRSMSX105.ger.corp.intel.com> References: <1406665466-29654-1-git-send-email-nhorman@tuxdriver.com> In-Reply-To: <1406665466-29654-1-git-send-email-nhorman@tuxdriver.com> 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 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:07:46 -0000 Hi Neil, =20 > Hey all- > I've been trying to update the fedora dpdk package to support VFI= O > enabled drivers and ran into a problem in which ixgbe didn't compile beca= use 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 intrinsic= s 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 bett= er. I > noted that code that uses intrinsics (ixgbe and the acl library), don't n= eed 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 optimization= s can > be used if the executing cpu supports them at run time. =20 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 =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 extremely fa= st. 2. Can you add RTE_LOG(ERR, ...) for re_acl_create() and ixgbe_rx_vec_condi= tion_check() if sse4.2 is not supported? Konstantin