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 72D3FA09E4; Thu, 28 Jan 2021 09:03:28 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3064C40692; Thu, 28 Jan 2021 09:03:28 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id CBF3A4068A for ; Thu, 28 Jan 2021 09:03:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611821006; 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=raCDUk6sZtcl0CUpmOAwicAk852ZpeLE1h9LwQpoB6g=; b=YYWOkO45BxXyYwNlnC9GywgSGLZ7mTe5e5u7fMKlDkZCUuhV6xMAPYD43hLC2fckrXI7fC UrKRJo0uPwm19HyznpqEhnGmVTsL+XZgZpbqh961n5qRQL7nB82Gp9+qzbip2JCE4oZaCf KtQe0+KgNZGRCwWCS9FTjifskS+svgs= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-319-hm_B8QnWPcGGfYmpKYx0qQ-1; Thu, 28 Jan 2021 03:03:24 -0500 X-MC-Unique: hm_B8QnWPcGGfYmpKYx0qQ-1 Received: by mail-vk1-f197.google.com with SMTP id v1so996089vkf.9 for ; Thu, 28 Jan 2021 00:03:23 -0800 (PST) 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=raCDUk6sZtcl0CUpmOAwicAk852ZpeLE1h9LwQpoB6g=; b=TLhb5QGnqL3CziValqhsK0k9l/ZkFL8RceLSBLRTNh25p+XspQ/4vvc83OOKggHATM SePlTTtPjDThe/xLX96wPuXzsMq8GEWOhUzQqnK1qKPykaw4pNBLdG7Pxbujapbm9wD6 JifJ8ScBKOWkcl4gfpi124+NHiWpqwsMcukCDcaM6KRtJtKOg+GLJ/WqrPW6VB2P2NKK dqAYa3t6HWqUc3CJrwtLJ4IZh6i39kHv50VpG1+WpczgsH+tuaEZe+k8cBPKmE97Kx7b wcOiMfsqZ0GtO7rd0cFY0wGbdR3DI3ymdYXe5i7eTpKrB2eFiVp8rIfYmJjASDI6Maaa dtJg== X-Gm-Message-State: AOAM532bw5X3ANHv5W/rRBg/XUNEX0wKMeqk4IX7SJzY/RH3RhXbZikR zY8Ag4jVy+9e6jXNGlbgEBAIzF/zkza5Onmg6+lEsFcZNRvHRklg2A6Y9q7uKFBav5fldThEJzl 14ZZaacRVlexe3YxfiFs= X-Received: by 2002:a05:6102:3136:: with SMTP id f22mr10600321vsh.17.1611821003448; Thu, 28 Jan 2021 00:03:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwUVjkrClJk5uJ2SfmVt/dmTJHRvD1ISb5L4kyLwcakzZE5wqH9lnCrnUbzjVgNMw7iJjo+Y1qvvNPT5omKzOs= X-Received: by 2002:a05:6102:3136:: with SMTP id f22mr10600314vsh.17.1611821003160; Thu, 28 Jan 2021 00:03:23 -0800 (PST) MIME-Version: 1.0 References: <20201218101210.356836-1-ruifeng.wang@arm.com> <20210112025709.1121523-1-ruifeng.wang@arm.com> <20210112025709.1121523-2-ruifeng.wang@arm.com> In-Reply-To: From: David Marchand Date: Thu, 28 Jan 2021 09:03:11 +0100 Message-ID: To: Honnappa Nagarahalli Cc: Ruifeng Wang , "jerinj@marvell.com" , Jan Viktorin , Bruce Richardson , Vladimir Medvedkin , dev , Pavan Nikhilesh , "hemant.agrawal@nxp.com" , nd 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 v3 1/5] lpm: add sve support for lookup on Arm platform 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 Sender: "dev" On Wed, Jan 27, 2021 at 10:03 PM Honnappa Nagarahalli wrote: > > > > > > > On Tue, Jan 12, 2021 at 3:57 AM Ruifeng Wang > > wrote: > > > diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h index > > > 1afe55cdc..28b57683b 100644 > > > --- a/lib/librte_lpm/rte_lpm.h > > > +++ b/lib/librte_lpm/rte_lpm.h > > > @@ -402,7 +402,11 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, > > xmm_t ip, uint32_t hop[4], > > > uint32_t defv); > > > > > > #if defined(RTE_ARCH_ARM) > > > +#ifdef __ARM_FEATURE_SVE > > > +#include "rte_lpm_sve.h" > > > +#else > > > #include "rte_lpm_neon.h" > > > +#endif > > > #elif defined(RTE_ARCH_PPC_64) > > > #include "rte_lpm_altivec.h" > > > #else > > > diff --git a/lib/librte_lpm/rte_lpm_sve.h > > > b/lib/librte_lpm/rte_lpm_sve.h new file mode 100644 index > > > 000000000..2e319373e > > > --- /dev/null > > > +++ b/lib/librte_lpm/rte_lpm_sve.h > > > @@ -0,0 +1,83 @@ > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > + * Copyright(c) 2020 Arm Limited > > > + */ > > > + > > > +#ifndef _RTE_LPM_SVE_H_ > > > +#define _RTE_LPM_SVE_H_ > > > + > > > +#include > > > + > > > +#ifdef __cplusplus > > > +extern "C" { > > > +#endif > > > + > > > +__rte_internal > > > +static void > > > > I was looking into use of the __rte_internal tag in the tree. > > > > This helper is called from a inlined API used by applications, so out of the > > DPDK build. > > It looks like the compiler is not complaining when compiling examples (I > > hacked my env to cross compile with gcc 10 + SVE enabled) but this seems > > incorrect to me. > > > > Is there really a need for this helper? > > It is only used below afaics. > I do not think it is required. > > At the same time the commit log when '__rte_internal' was introduced is confusing. > It says "Introduce the __rte_internal tag to mark internal ABI function which is used only by the drivers or other libraries". Why would an internal function have an ABI? It happens that drivers/libraries in DPDK offer some interface for other parts of the DPDK to use. But we might want them to keep them hidden to final applications, because this is purely internal and/or we don't want to guarantee compatibility in later versions. For such cases, a function can be marked __rte_internal. This tag has two impacts: - a marked symbol is versionned as INTERNAL when exported (so this does not apply to inlines), - if an application tries to use a marked API, an error is triggered at build time to prevent use of such API, -- David Marchand