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 0C6A0A0540; Thu, 16 Jul 2020 06:58:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D8C941BEA8; Thu, 16 Jul 2020 06:58:07 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by dpdk.org (Postfix) with ESMTP id 3B1944F9A for ; Thu, 16 Jul 2020 06:58:06 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BDA3731B; Wed, 15 Jul 2020 21:58:05 -0700 (PDT) Received: from phil-VirtualBox.shanghai.arm.com (phil-VirtualBox.shanghai.arm.com [10.169.109.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 866CB3F66B; Wed, 15 Jul 2020 21:58:01 -0700 (PDT) From: Phil Yang To: thomas@monjalon.net, john.mcnamara@intel.com, Honnappa.Nagarahalli@arm.com, drc@linux.vnet.ibm.com, dev@dpdk.org Cc: david.marchand@redhat.com, jerinj@marvell.com, konstantin.ananyev@intel.com, Ola.Liljedahl@arm.com, bruce.richardson@intel.com, Ruifeng.Wang@arm.com, nd@arm.com, Honnappa Nagarahalli , Marko Kovacevic Date: Thu, 16 Jul 2020 12:53:42 +0800 Message-Id: <1594875225-5850-2-git-send-email-phil.yang@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1594875225-5850-1-git-send-email-phil.yang@arm.com> References: <1594621423-14796-1-git-send-email-phil.yang@arm.com> <1594875225-5850-1-git-send-email-phil.yang@arm.com> Subject: [dpdk-dev] [PATCH v8 1/3] doc: add optimizations using C11 atomic built-ins 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" Add information about possible optimizations using C11 atomic built-ins. Signed-off-by: Phil Yang Signed-off-by: Honnappa Nagarahalli --- doc/guides/prog_guide/writing_efficient_code.rst | 59 +++++++++++++++++++++++- 1 file changed, 58 insertions(+), 1 deletion(-) diff --git a/doc/guides/prog_guide/writing_efficient_code.rst b/doc/guides/prog_guide/writing_efficient_code.rst index 849f63e..53a1ca1 100644 --- a/doc/guides/prog_guide/writing_efficient_code.rst +++ b/doc/guides/prog_guide/writing_efficient_code.rst @@ -167,7 +167,13 @@ but with the added cost of lower throughput. Locks and Atomic Operations --------------------------- -Atomic operations imply a lock prefix before the instruction, +This section describes some key considerations when using locks and atomic +operations in the DPDK environment. + +Locks +~~~~~ + +On x86, atomic operations imply a lock prefix before the instruction, causing the processor's LOCK# signal to be asserted during execution of the following instruction. This has a big impact on performance in a multicore environment. @@ -176,6 +182,57 @@ It can often be replaced by other solutions like per-lcore variables. Also, some locking techniques are more efficient than others. For instance, the Read-Copy-Update (RCU) algorithm can frequently replace simple rwlocks. +Atomic Operations: Use C11 Atomic Built-ins +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +DPDK generic rte_atomic operations are implemented by __sync built-ins. These +__sync built-ins result in full barriers on aarch64, which are unnecessary +in many use cases. They can be replaced by __atomic built-ins that conform to +the C11 memory model and provide finer memory order control. + +So replacing the rte_atomic operations with __atomic built-ins might improve +performance for aarch64 machines. + +Some typical optimization cases are listed below: + +Atomicity +^^^^^^^^^ + +Some use cases require atomicity alone, the ordering of the memory operations +does not matter. For example, the packet statistics counters need to be +incremented atomically but do not need any particular memory ordering. +So, RELAXED memory ordering is sufficient. + +One-way Barrier +^^^^^^^^^^^^^^^ + +Some use cases allow for memory reordering in one way while requiring memory +ordering in the other direction. + +For example, the memory operations before the spinlock lock are allowed to +move to the critical section, but the memory operations in the critical section +are not allowed to move above the lock. In this case, the full memory barrier +in the compare-and-swap operation can be replaced with ACQUIRE memory order. +On the other hand, the memory operations after the spinlock unlock are allowed +to move to the critical section, but the memory operations in the critical +section are not allowed to move below the unlock. So the full barrier in the +store operation can use RELEASE memory order. + +Reader-Writer Concurrency +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Lock-free reader-writer concurrency is one of the common use cases in DPDK. + +The payload or the data that the writer wants to communicate to the reader, +can be written with RELAXED memory order. However, the guard variable should +be written with RELEASE memory order. This ensures that the store to guard +variable is observable only after the store to payload is observable. + +Correspondingly, on the reader side, the guard variable should be read +with ACQUIRE memory order. The payload or the data the writer communicated, +can be read with RELAXED memory order. This ensures that, if the store to +guard variable is observable, the store to payload is also observable. + Coding Considerations --------------------- -- 2.7.4