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 E3319A052A; Wed, 27 Jan 2021 14:04:51 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 839D8140D8E; Wed, 27 Jan 2021 14:04:51 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 42C1E140D75 for ; Wed, 27 Jan 2021 14:04:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611752689; 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=j83EaH2wicxXLdnnAce/M6fMfvofRskt/1kiWYzzma4=; b=G0OIsf+hhXNW51hLSUqY5Fo+cdN9/9NgvCoRQdp/CfP5a0ehTsHre5AxKsm773gfUV5tBS rgaMKgBtNIkesJTdLCk8ifMRhQeiJbubXkfSulvoKYx7EMLfD5SiMU5SbiQxqRHqD2xYRQ xxDtA7SwInPVbjrVtI9iJiJBFCnPsDA= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-490-t-ebDh0AM-m7yB-pZavyaA-1; Wed, 27 Jan 2021 08:04:47 -0500 X-MC-Unique: t-ebDh0AM-m7yB-pZavyaA-1 Received: by mail-vs1-f72.google.com with SMTP id 188so353853vsl.13 for ; Wed, 27 Jan 2021 05:04:47 -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=j83EaH2wicxXLdnnAce/M6fMfvofRskt/1kiWYzzma4=; b=iCLyhbtOL1YpzIF3WOKpT6nJ+8QxCmzvV2dcnmAQ/P1a29LEZArYi7CjZZnzF+ayCn vPu5Wc8JYBfzsneOn776uTHp+2xvSPvvDrRSYSjuGrMlGeJqym+dCXtNn47tGBnVLQMi UUxlhKcEnX04g4DmkPRSYlUl3TgoR+t5axZrxscSSc4TGMz7rnkg+C1Xx8eeQw4TvlDZ v6p4UVsHAE6GdCB/jEeXue2dk2289RMcIeZyNQW14dSuGnUabZeKyxTcHKz3bYRDZw/d HWsYhCmTywnub4IKMqsSgt9SeU+jJHaxFVoIpr5cNVHC29I07t2ZtH28dJCF/SvyJZ8+ WhyA== X-Gm-Message-State: AOAM533CquwOn0GuBor/iSYJpGR4F7X8W/6b5gYg3nkV87PPPh8tYlRC v5KY9JffPvYFDANQw6ETO6wyATnltErhxOnmJkndBLIOdLiWxAM0YHV5oXHpKZnnfbY+IHJNZlG qqVi1u50qtFRkOH3Hlpo= X-Received: by 2002:a9f:2628:: with SMTP id 37mr7469294uag.87.1611752687011; Wed, 27 Jan 2021 05:04:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQjxp7CYhY4VCuULKl59OsL7Zh0Hs9WbBghyPpNLe3pJSsDeRbEZ0blRepMGXYuAs6aRIynOja4VADNHZqbMk= X-Received: by 2002:a9f:2628:: with SMTP id 37mr7469248uag.87.1611752686649; Wed, 27 Jan 2021 05:04:46 -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: <20210112025709.1121523-2-ruifeng.wang@arm.com> From: David Marchand Date: Wed, 27 Jan 2021 14:04:35 +0100 Message-ID: To: Ruifeng Wang Cc: Jerin Jacob , Jan Viktorin , Bruce Richardson , Vladimir Medvedkin , dev , Pavan Nikhilesh , Hemant Agrawal , Honnappa Nagarahalli , 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 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. > +__rte_lpm_lookup_vec(const struct rte_lpm *lpm, const uint32_t *ips, > + uint32_t *__rte_restrict next_hops, const uint32_t n) > +{ [snip] > +} > + > +static inline void > +rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip, uint32_t hop[4], > + uint32_t defv) > +{ > + uint32_t i, ips[4]; > + > + vst1q_s32((int32_t *)ips, ip); > + for (i = 0; i < 4; i++) > + hop[i] = defv; > + > + __rte_lpm_lookup_vec(lpm, ips, hop, 4); > +} -- David Marchand