From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
 Ray Kinsella <mdr@ashroe.eu>, Thomas Monjalon <thomas@monjalon.net>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 Bruce Richardson <bruce.richardson@intel.com>,
 Ciara Power <ciara.power@intel.com>
References: <cover.1603102577.git.vladimir.medvedkin@intel.com>
 <cover.1603119828.git.vladimir.medvedkin@intel.com>
 <de5ef91ffa2e9a8184be2b768eac23fd79172abe.1603119828.git.vladimir.medvedkin@intel.com>
 <CAJFAV8xt9tuxOsmm6OWZEz+-sB9gD0dtYBiaTbvcZDzsUsV5Kw@mail.gmail.com>
 <1d5e4e32-f74f-7749-ec28-3f2b5725c27a@intel.com>
 <CAJFAV8yoQiLmkjOmaNkmqu6cX3Lp2cOv4Uc4mXiWO9Od0KD_cg@mail.gmail.com>
From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
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: <CAJFAV8yoQiLmkjOmaNkmqu6cX3Lp2cOv4Uc4mXiWO9Od0KD_cg@mail.gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hello,

On 23/10/2020 11:29, David Marchand wrote:
> On Thu, Oct 22, 2020 at 5:12 PM Medvedkin, Vladimir
> <vladimir.medvedkin@intel.com> wrote:
>>
>> Hi David,
>>
>> On 22/10/2020 12:52, David Marchand wrote:
>>> On Mon, Oct 19, 2020 at 5:05 PM Vladimir Medvedkin
>>> <vladimir.medvedkin@intel.com> 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 <vladimir.medvedkin@intel.com>
>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>>>
>>> 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