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 A37D4A04F3; Fri, 20 Dec 2019 04:34:08 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C7D671BDFD; Fri, 20 Dec 2019 04:34:07 +0100 (CET) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id EA2091BC25 for ; Fri, 20 Dec 2019 04:34:05 +0100 (CET) Received: by mail-io1-f67.google.com with SMTP id b10so7989065iof.11 for ; Thu, 19 Dec 2019 19:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hkIieKFEaeggOsZurM//eh91ZcL8AOAJOPtmscQOfjQ=; b=ZQM7xTd0bTvhz6JtHFLSIIXsEfge5hRvHj0TZFbfxCPqErTtdslxBnpA/fbacNEpEK 7ibOqZmHqmCbj5x34t3vYOzATVi47rnTkV3SvjVBG+Clbo6GEeMLw3iny9UImoe8oy3Z yF+qq/eUKhN8sIRUhPl2TYIKp+er92HQMPtqGMqpYFNk+ch4sRpiWaZiwDEW737Naehm KhcdzWGzpQNSo2VpRMllsfIX3AfKrq2+H0eAJW7BSMXl/RCxQQDdk475UOmZrE9GMDS2 q+j7XbBqbHrpUCQhvAxyZoc6MOMCCMbP07x8nRN59ZWoRsXHhBbE/W4bWLeZ7YqXN4JP zyYg== 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=hkIieKFEaeggOsZurM//eh91ZcL8AOAJOPtmscQOfjQ=; b=MWe0yW1fldj5cn/SeVtE7RqX52HSK2DFkbe4YAfS9eIoIh2XaIEmm9o428pR/OLIDB Bbt6xLE5i7YtfXnW0dSfj9kvUWWt81CvT4nFpa4yK+j7gYv9xtVjv1j+81BC5Ppw4cm2 ICJ6ZKu1rVM7YkaCv+oJNdsAUOX/+VjeVqW1UU0rtNu7vS8EVRJTfq1QC6yjVGho+iNX nDrNo+Lhddz4UxUEQC6VWQvlapH3mj6feW0B+71yENovw3+QLWwpSyE7R9monxE5knTk tPP2IOUSV0X4GfNHFsQpSsNIVklaFWmrfvLBSo+yCTA/F3OAagXLgVrhTWzQVqghc8ay AqQw== X-Gm-Message-State: APjAAAUoLMkY1NP0kL4CQCK08PX7KRedbI4r65dojRSA/wwAyFiKtKH5 8i8xZjotRbR+vTFjV3V522Ky+Ufm+WEfR0bCRKo= X-Google-Smtp-Source: APXvYqxpbhmFrWEq4aazOAY3aBKGVMzKkKWX57s82ThsP4VsFaW1FMMQMFThWr5A+rtyYGgWVoluGuVv6Ben8OAjbxc= X-Received: by 2002:a5e:8516:: with SMTP id i22mr8829658ioj.130.1576812844945; Thu, 19 Dec 2019 19:34:04 -0800 (PST) MIME-Version: 1.0 References: <1571758074-16445-1-git-send-email-gavin.hu@arm.com> <1576811391-19131-1-git-send-email-gavin.hu@arm.com> <1576811391-19131-2-git-send-email-gavin.hu@arm.com> In-Reply-To: <1576811391-19131-2-git-send-email-gavin.hu@arm.com> From: Jerin Jacob Date: Fri, 20 Dec 2019 09:03:48 +0530 Message-ID: To: Gavin Hu Cc: dpdk-dev , nd , David Marchand , Thomas Monjalon , rasland@mellanox.com, maxime.coquelin@redhat.com, tiwei.bie@intel.com, Hemant Agrawal , Jerin Jacob , Pavan Nikhilesh , Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , Phil Yang , Joyce Kong , Steve Capper Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for aarch64 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 Fri, Dec 20, 2019 at 8:40 AM Gavin Hu wrote: > > Armv8's peripheral coherence order is a total order on all reads and writes > to that peripheral.[1] > > The peripheral coherence order for a memory-mapped peripheral signifies the > order in which accesses arrive at the endpoint. For a read or a write RW1 > and a read or a write RW2 to the same peripheral, then RW1 will appear in > the peripheral coherence order for the peripheral before RW2 if either of > the following cases apply: > 1. RW1 and RW2 are accesses using Non-cacheable or Device attributes and > RW1 is Ordered-before RW2. > 2. RW1 and RW2 are accesses using Device-nGnRE or Device-nGnRnE attributes > and RW1 appears in program order before RW2. This is true if RW1 and RW2 addresses are device memory. i.e the registers in the PCI bar address. If RW1 is DDR address which is been used by the controller(say NIC ring descriptor) then there will be an issue. For example Intel i40e driver, the admin queue update in Host DDR memory and it updates the doorbell. In such a case, this patch will create an issue. Correct? Have you checked this patch with ARM64 + XL710 controllers? Some of the legacy code is missing such barriers, that's the reason for adding rte_io_* barrier. > > On arm platforms, all the PCI resources are mapped to nGnRE device memory > [2], the above case 2 holds true, that means the peripheral coherence order > applies here and just a compiler barrier is sufficient for rte io barriers. > > [1] Section B2.3.4 of ARMARM, https://developer.arm.com/docs/ddi0487/lates > t/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > tree/drivers/pci/pci-sysfs.c#n1204 > > Signed-off-by: Gavin Hu > Reviewed-by: Steve Capper > Reviewed-by: Phil Yang > --- > lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h > index 859ae12..fd63956 100644 > --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h > +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h > @@ -34,11 +34,11 @@ extern "C" { > > #define rte_smp_rmb() dmb(ishld) > > -#define rte_io_mb() rte_mb() > +#define rte_io_mb() rte_compiler_barrier() > > -#define rte_io_wmb() rte_wmb() > +#define rte_io_wmb() rte_compiler_barrier() > > -#define rte_io_rmb() rte_rmb() > +#define rte_io_rmb() rte_compiler_barrier() > > #define rte_cio_wmb() dmb(oshst) > > -- > 2.7.4 >