From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.161.173]) by dpdk.org (Postfix) with ESMTP id 732412BFF for ; Thu, 15 Dec 2016 11:17:33 +0100 (CET) Received: by mail-yw0-f173.google.com with SMTP id a10so11107816ywa.3 for ; Thu, 15 Dec 2016 02:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ufxo177/ig25YjTfsIE6zReMix0Q9J9t4iU5pccrVMs=; b=h3Yl7sK3cQ7g7w9E9FeCGOoFvRGfvK+O78OCXV7T9Ze08/0KH2e0quFzWCwFj/rYaY exCy09Qm1K6YVGpJpmWImw9H2iGxZR0rsZWpdd60WB7hbvTrwmL427S6FUZ2rf1T2IRA vV1LteeRjeIQ4ybMyRRCKWbBNi1huvhTvnZsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ufxo177/ig25YjTfsIE6zReMix0Q9J9t4iU5pccrVMs=; b=c1oOtdazy7ddWCW45F2Zn+AyL+e9SB7/jXU+IhllutDkzzRy9gGmkVY7SS7RgvDYLX WL6PHUULCHgRJNrwE6wJDg42tdlU5rIyScR+3I1oCoCFZT7uCORYD5J6aZFKaaBCoLxx LoYTFO+kGZMGEB51X8rZyrCbOcEJP2YGnHoJN93zCYMyfv/0q9GV9iGxsEHVXHEdEWfr ilPMunxMvt6lD3hTm0O4KoD079laA1YOMappHDV+FKRoBK8cDYkQmh833XcetDzGtwmb Fk+PLWCywpA/07+yLywqWcCbQfKAF9eQa2iXq7dLZ/iXF/Vtz7XRR1HZxad2Gp0reqyD jsWw== X-Gm-Message-State: AIkVDXLQEM1uIC2JMYUL+ZfdZ+6EhXBqjyuetMqENjapf6eyX9ws3TmQMo4IaDP3mQLq+sdD6D0rCw0Bd14zJOdi X-Received: by 10.13.223.147 with SMTP id i141mr480576ywe.32.1481797052752; Thu, 15 Dec 2016 02:17:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.193.131 with HTTP; Thu, 15 Dec 2016 02:17:32 -0800 (PST) In-Reply-To: <20161215100423.GA6712@localhost.localdomain> References: <1481680558-4003-1-git-send-email-jerin.jacob@caviumnetworks.com> <1481680558-4003-14-git-send-email-jerin.jacob@caviumnetworks.com> <20161215100423.GA6712@localhost.localdomain> From: Jianbo Liu Date: Thu, 15 Dec 2016 18:17:32 +0800 Message-ID: To: Jerin Jacob Cc: dev@dpdk.org, "Ananyev, Konstantin" , Thomas Monjalon , Bruce Richardson , Jan Viktorin Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH 13/28] eal/arm64: override I/O device read/write access for arm64 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: , X-List-Received-Date: Thu, 15 Dec 2016 10:17:33 -0000 On 15 December 2016 at 18:04, Jerin Jacob wrote: > On Thu, Dec 15, 2016 at 05:53:05PM +0800, Jianbo Liu wrote: >> On 14 December 2016 at 09:55, Jerin Jacob >> wrote: >> > Override the generic I/O device memory read/write access and implement it >> > using armv8 instructions for arm64. >> > >> > Signed-off-by: Jerin Jacob >> > --- >> > lib/librte_eal/common/include/arch/arm/rte_io.h | 4 + >> > lib/librte_eal/common/include/arch/arm/rte_io_64.h | 183 +++++++++++++++++++++ >> > 2 files changed, 187 insertions(+) >> > create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io_64.h >> > >> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_io.h b/lib/librte_eal/common/include/arch/arm/rte_io.h >> > index 74c1f2c..9593b42 100644 >> > --- a/lib/librte_eal/common/include/arch/arm/rte_io.h >> > +++ b/lib/librte_eal/common/include/arch/arm/rte_io.h >> > @@ -38,7 +38,11 @@ >> > extern "C" { >> > #endif >> > >> > +#ifdef RTE_ARCH_64 >> > +#include "rte_io_64.h" >> > +#else >> > #include "generic/rte_io.h" >> > +#endif >> > >> > #ifdef __cplusplus >> > } >> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_io_64.h b/lib/librte_eal/common/include/arch/arm/rte_io_64.h >> > new file mode 100644 >> > index 0000000..09e7a89 >> > --- /dev/null >> > +++ b/lib/librte_eal/common/include/arch/arm/rte_io_64.h >> > @@ -0,0 +1,183 @@ >> > +/* >> > + * BSD LICENSE >> > + * >> > + * Copyright (C) Cavium networks Ltd. 2016. >> > + * >> > + * Redistribution and use in source and binary forms, with or without >> > + * modification, are permitted provided that the following conditions >> > + * are met: >> > + * >> > + * * Redistributions of source code must retain the above copyright >> > + * notice, this list of conditions and the following disclaimer. >> > + * * Redistributions in binary form must reproduce the above copyright >> > + * notice, this list of conditions and the following disclaimer in >> > + * the documentation and/or other materials provided with the >> > + * distribution. >> > + * * Neither the name of Cavium networks nor the names of its >> > + * contributors may be used to endorse or promote products derived >> > + * from this software without specific prior written permission. >> > + * >> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS >> > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >> > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR >> > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT >> > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, >> > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >> > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, >> > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY >> > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT >> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE >> > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. >> > + */ >> > + >> > +#ifndef _RTE_IO_ARM64_H_ >> > +#define _RTE_IO_ARM64_H_ >> > + >> > +#ifdef __cplusplus >> > +extern "C" { >> > +#endif >> > + >> > +#include >> > + >> > +#define RTE_OVERRIDE_IO_H >> > + >> > +#include "generic/rte_io.h" >> > +#include "rte_atomic_64.h" >> > + >> > +static inline __attribute__((always_inline)) uint8_t >> > +__rte_arm64_readb(const volatile void *addr) >> > +{ >> > + uint8_t val; >> > + >> > + asm volatile( >> > + "ldrb %w[val], [%x[addr]]" >> > + : [val] "=r" (val) >> > + : [addr] "r" (addr)); >> > + return val; >> > +} >> > + >> > +static inline __attribute__((always_inline)) uint16_t >> > +__rte_arm64_readw(const volatile void *addr) >> > +{ >> > + uint16_t val; >> > + >> > + asm volatile( >> > + "ldrh %w[val], [%x[addr]]" >> > + : [val] "=r" (val) >> > + : [addr] "r" (addr)); >> > + return val; >> > +} >> > + >> > +static inline __attribute__((always_inline)) uint32_t >> > +__rte_arm64_readl(const volatile void *addr) >> > +{ >> > + uint32_t val; >> > + >> > + asm volatile( >> > + "ldr %w[val], [%x[addr]]" >> > + : [val] "=r" (val) >> > + : [addr] "r" (addr)); >> > + return val; >> > +} >> > + >> > +static inline __attribute__((always_inline)) uint64_t >> > +__rte_arm64_readq(const volatile void *addr) >> > +{ >> > + uint64_t val; >> > + >> > + asm volatile( >> > + "ldr %x[val], [%x[addr]]" >> > + : [val] "=r" (val) >> > + : [addr] "r" (addr)); >> > + return val; >> > +} >> > + >> > +static inline __attribute__((always_inline)) void >> > +__rte_arm64_writeb(uint8_t val, volatile void *addr) >> > +{ >> > + asm volatile( >> > + "strb %w[val], [%x[addr]]" >> > + : >> > + : [val] "r" (val), [addr] "r" (addr)); >> > +} >> > + >> > +static inline __attribute__((always_inline)) void >> > +__rte_arm64_writew(uint16_t val, volatile void *addr) >> > +{ >> > + asm volatile( >> > + "strh %w[val], [%x[addr]]" >> > + : >> > + : [val] "r" (val), [addr] "r" (addr)); >> > +} >> > + >> > +static inline __attribute__((always_inline)) void >> > +__rte_arm64_writel(uint32_t val, volatile void *addr) >> > +{ >> > + asm volatile( >> > + "str %w[val], [%x[addr]]" >> > + : >> > + : [val] "r" (val), [addr] "r" (addr)); >> > +} >> > + >> > +static inline __attribute__((always_inline)) void >> > +__rte_arm64_writeq(uint64_t val, volatile void *addr) >> > +{ >> > + asm volatile( >> > + "str %x[val], [%x[addr]]" >> > + : >> > + : [val] "r" (val), [addr] "r" (addr)); >> > +} >> >> I'm not quite sure about these overridings. Can you explain the >> benefit to do so? > > Better to be native if there is option. That all. Do you see any issue? > or what is the real concern? > I think it's the same as the generic c version after compiling. Am I right? If there is no apparent benefit, I don't think we need the overriding.