From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 62BAEA04DD; Fri, 23 Oct 2020 18:09:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B89055A57; Fri, 23 Oct 2020 18:09:21 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 495815A2D for ; Fri, 23 Oct 2020 18:09:19 +0200 (CEST) IronPort-SDR: hYACku21fwIVlZJEwmke13CsUmOw5hT/b7b96Fab3IqkCjd2enoQZW34Ai+3rw/N8Pz8BOlCu5 ItSoSO34NF4w== X-IronPort-AV: E=McAfee;i="6000,8403,9782"; a="164202211" X-IronPort-AV: E=Sophos;i="5.77,409,1596524400"; d="scan'208";a="164202211" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2020 09:09:12 -0700 IronPort-SDR: hwvtT3QJ1jWtYRH+y4biQSJE75W74KdF9PwJGVqt29jrF9KWdspzhfn9EGbSfNyYqX30APX4iU 4AYOSxPW0oag== X-IronPort-AV: E=Sophos;i="5.77,409,1596524400"; d="scan'208";a="534444159" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.251.87.157]) ([10.251.87.157]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2020 09:09:10 -0700 To: David Marchand Cc: dev , Jerin Jacob Kollanukkaran , Ray Kinsella , Thomas Monjalon , "Ananyev, Konstantin" , Bruce Richardson , Ciara Power References: <1d5e4e32-f74f-7749-ec28-3f2b5725c27a@intel.com> From: "Medvedkin, Vladimir" Message-ID: <58177c06-ace5-40eb-e8d9-3be0625973d6@intel.com> Date: Fri, 23 Oct 2020 17:09:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v13 1/7] fib: make lookup function type configurable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Archived-At: List-Archive: Hello, On 23/10/2020 11:29, David Marchand wrote: > On Thu, Oct 22, 2020 at 5:12 PM Medvedkin, Vladimir > wrote: >> >> Hi David, >> >> On 22/10/2020 12:52, David Marchand wrote: >>> On Mon, Oct 19, 2020 at 5:05 PM Vladimir Medvedkin >>> wrote: >>>> >>>> Add type argument to dir24_8_get_lookup_fn() >>>> Now it supports 3 different lookup implementations: >>>> RTE_FIB_DIR24_8_SCALAR_MACRO >>>> RTE_FIB_DIR24_8_SCALAR_INLINE >>>> RTE_FIB_DIR24_8_SCALAR_UNI >>>> >>>> Add new rte_fib_set_lookup_fn() - user can change lookup >>>> function type runtime. >>>> >>>> Signed-off-by: Vladimir Medvedkin >>>> Acked-by: Konstantin Ananyev >>> >>> We create a fib object with a type: either RTE_FIB_DUMMY or >>> RTE_FIB_DIR24_8 (separate topic, we probably do not need >>> RTE_FIB_TYPE_MAX). >> RTE_FIB_TYPE_MAX is used for early sanity check. I can remove it >> (relying on that init_dataplane() will return error for improper type), >> if you think that it is better to get rid of it. > > Applications could start using it. > If you don't need it, don't expose it. > > A validation on type <= RTE_FIB_DIR24_8 should be enough. > Will remove it in v14, thanks! > >> >>> >>> This lookup API is dir24_8 specific. >>> If we won't abstract the lookup selection type, why not change this >>> API as dir24_8 specific? >>> I.e. s/rte_fib_set_lookup_fn/rte_fib_dir24_8_set_lookup_fn/g >>> >>> The same would apply to FIB6 trie implementation. >> >> Good point. In future I want to add more data plane algorithms such as >> DXR or Poptrie for example. In this case I don't really want to have >> separate function for every supported algorithm, i.e. I think it is >> better to have single rte_fib_set_lookup_fn(). But on the other hand it >> needs to be generic in this case. In future releases I want to get rid >> of different dir24_8's scalar implementations (MACRO/INLINE/UNI). After >> this we can change types to algorithm agnostic names: >> RTE_FIB_SCALAR, >> RTE_FIB_VECTOR_AVX512 > > Is there a real benefit from those 3 scalar lookup implementations for dir24_8 ? > Initially I've sent 3 different implementations to get responses from the community what implementation should I leave. Test results on different IA CPU's shows that MACRO based implementation perform slightly faster. So I think there is no benefit from keeping other implementations. > -- Regards, Vladimir