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 CBDF6A04DD; Thu, 22 Oct 2020 17:12:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DF6875A9C; Thu, 22 Oct 2020 17:11:58 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0917E594B for ; Thu, 22 Oct 2020 17:11:55 +0200 (CEST) IronPort-SDR: PTE/hayUucvlNy5Ybkd3mtbp4ZFuPCI5im5OVd0iI6trIBAtN2c4uTTdCqT5W9WRtUsno++Hni O8dPidmKfcKA== X-IronPort-AV: E=McAfee;i="6000,8403,9781"; a="185224012" X-IronPort-AV: E=Sophos;i="5.77,404,1596524400"; d="scan'208";a="185224012" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2020 08:11:50 -0700 IronPort-SDR: 5MC5Lmo9KE71Q5WsUIKMTvAjAt3wcZutTp61V9ZFXCToIDZlVtaJ8zVih1NKaf+Avog8R/Z/6a nW3cjzj5F2Xg== X-IronPort-AV: E=Sophos;i="5.77,404,1596524400"; d="scan'208";a="534003902" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.251.85.42]) ([10.251.85.42]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2020 08:11:42 -0700 To: David Marchand Cc: dev , Jerin Jacob Kollanukkaran , Ray Kinsella , Thomas Monjalon , "Ananyev, Konstantin" , Bruce Richardson , Ciara Power References: From: "Medvedkin, Vladimir" Message-ID: <1d5e4e32-f74f-7749-ec28-3f2b5725c27a@intel.com> Date: Thu, 22 Oct 2020 16:11:36 +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" 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. > > 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 > -- Regards, Vladimir