From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C736CA00C4; Mon, 30 May 2022 09:52:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 783B740A8A; Mon, 30 May 2022 09:52:30 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id A4CC340A89 for ; Mon, 30 May 2022 09:52:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653897148; x=1685433148; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gBVenH4F1uyhzqKkO6xpPkkyKKaxSwBxh4HeG2SwKtY=; b=TFynzunO3hHpNPZmlP1tRYRguyNgCsk6qZXWmF+DSLCeTSBUPAuGtbyU erRQ4PLmG6GW2Ytl8Cjfn+dZ5Ligj5evTesXHV7vpoPImoMknibbwFNdO VWl4Oczl9QLOOhD19CieT4Pnt4R5E9DKWrAhrpQtKGAp0kCCDHAsz8p07 3LjR5N3bU9FIhvvamLrty37z6un9/wN3LOy4GML7q8cPjYdUwuMNuOzrD tv4Dkk77x6eMzTEhAw09xRpCb+FJXw7Uvw9uqcrtwhlb7LcTuFSYsF8DT ExhzNroiTkNM0D8ZbimSoVlxV3EOZMdDzb2sf87zXJNNfcc6+ntTB9bWH g==; X-IronPort-AV: E=McAfee;i="6400,9594,10362"; a="274645114" X-IronPort-AV: E=Sophos;i="5.91,262,1647327600"; d="scan'208";a="274645114" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2022 00:52:27 -0700 X-IronPort-AV: E=Sophos;i="5.91,262,1647327600"; d="scan'208";a="666407164" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.6.54]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 30 May 2022 00:52:25 -0700 Date: Mon, 30 May 2022 08:52:22 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: Stanislaw Kardach , Vladimir Medvedkin , Michal Mazurek , dev@dpdk.org, Frank Zhao , Sam Grove , mw@semihalf.com, upstream@semihalf.com Subject: Re: [PATCH v2 2/2] lpm: add a scalar version of lookupx4 function Message-ID: References: <20220510115824.457885-1-kda@semihalf.com> <20220527181822.716758-1-kda@semihalf.com> <20220527181822.716758-2-kda@semihalf.com> <20220527131520.23d9f544@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220527131520.23d9f544@hermes.local> X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, May 27, 2022 at 01:15:20PM -0700, Stephen Hemminger wrote: > On Fri, 27 May 2022 20:18:22 +0200 > Stanislaw Kardach wrote: > > > +static inline void > > +rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip, uint32_t hop[4], > > + uint32_t defv) > > +{ > > + uint32_t nh; > > + int i, ret; > > + > > + for (i = 0; i < 4; i++) { > > + ret = rte_lpm_lookup(lpm, ((rte_xmm_t)ip).u32[i], &nh); > > + hop[i] = (ret == 0) ? nh : defv; > > + } > > +} > > For performance, manually unroll the loop. Given a constant 4x iterations, will compilers not unroll this automatically. I think the loop is a little clearer if it can be kept /Bruce