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 C62DEA04DE; Fri, 23 Oct 2020 12:29:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E0AAAA93D; Fri, 23 Oct 2020 12:29:45 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id 7BEF45A36 for ; Fri, 23 Oct 2020 12:29:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603448981; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=a1y+ToWLosHiaJn3Hb48T5c85F+VeUtxPJUacaXybaY=; b=ctJljX0ZT5snKw2t7T3vpxOuUxbPpgGGcyU9uXIst75EdoDPUXnyIovuFtPezeZzdLKMYo dUaCAERHrXn91A4Z2pUkjKPgDp5ojP53qvjLD3ltM0gHnUlPcR3pGo+Z8tCHaTKv+GsBtB HZMiPZ9zhkuHG8Yk3aFYi7i/wVgvQ04= Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-371-frOESXLgPeCBbza65YPefg-1; Fri, 23 Oct 2020 06:29:40 -0400 X-MC-Unique: frOESXLgPeCBbza65YPefg-1 Received: by mail-vs1-f70.google.com with SMTP id g5so238595vsg.14 for ; Fri, 23 Oct 2020 03:29:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a1y+ToWLosHiaJn3Hb48T5c85F+VeUtxPJUacaXybaY=; b=bE7EzPsujf7QgtgVzIAwC4NACsmzoXnAWjcnkkPneC+rsEGA+zDGcBCfvLh0M8/PJw DYfwKfLZTX+1Ri5fDGkTER/YP6qv/+0B4pWw7zdbKvvcMJWG9Ra8wJNHkbY1s7uCxwHf 4f3lPw+jci8wZTme9s7OMu9il7GLHInMmBjGheOZLjeMMKN2mjc36s9gI0T6G7Imrwas JDL9/++0ejsW29x7YxDcxgByxHL9dT15EuZA5FNIbmPdi2Udrtl5wDTgBByFmaHpxZqw ek9P1BR2XhQqAPDYrFTAwbn3FgYHzD9j88e7bu2vaodcYIJJrrm2CZncE0sR74pTDpP9 1Icw== X-Gm-Message-State: AOAM532AKRTlxPB8JUkdJ4yV8QK6YgdhcRCGFqeYjkHgdl2git4fPUDf pFtguId0vt/7vvOHIQDchr99VL5qETxZxVnR6KUeCsI9IjZUfjqax7wv42Nef7vaSjlNLnBlV6f QfrW7asY6vy1bmu5IXmA= X-Received: by 2002:ab0:4983:: with SMTP id e3mr745990uad.41.1603448979756; Fri, 23 Oct 2020 03:29:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybMP3w9dO6KcYCm3wp/xXN+WF/z/DmmHY0IS7u1k1aoezXI3ITBQX9UdMlsovWVOfGYM8B1yPyQmGQOgqx1H8= X-Received: by 2002:ab0:4983:: with SMTP id e3mr745983uad.41.1603448979536; Fri, 23 Oct 2020 03:29:39 -0700 (PDT) MIME-Version: 1.0 References: <1d5e4e32-f74f-7749-ec28-3f2b5725c27a@intel.com> In-Reply-To: <1d5e4e32-f74f-7749-ec28-3f2b5725c27a@intel.com> From: David Marchand Date: Fri, 23 Oct 2020 12:29:28 +0200 Message-ID: To: "Medvedkin, Vladimir" Cc: dev , Jerin Jacob Kollanukkaran , Ray Kinsella , Thomas Monjalon , "Ananyev, Konstantin" , Bruce Richardson , Ciara Power Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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" 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. > > > > > 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 ? -- David Marchand