From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by dpdk.org (Postfix) with ESMTP id C468BDE0 for ; Tue, 29 May 2018 07:28:24 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 10E6480D; Mon, 28 May 2018 22:28:24 -0700 (PDT) Received: from ubuntu.localdomain (unknown [10.119.48.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5ED2A3F53D; Mon, 28 May 2018 22:28:23 -0700 (PDT) From: Honnappa Nagarahalli To: olivier.matz@6wind.com Cc: dev@dpdk.org, Honnappa Nagarahalli Date: Tue, 29 May 2018 00:28:14 -0500 Message-Id: <1527571694-121047-1-git-send-email-honnappa.nagarahalli@arm.com> X-Mailer: git-send-email 2.7.4 Subject: [dpdk-dev] [PATCH v2] rte_ring: clarify preemptible nature of ring algorithm 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: Tue, 29 May 2018 05:28:25 -0000 rte_ring implementation is not preemptible only under certain circumstances. This clarification is helpful for data plane and control plane communication using rte_ring. Signed-off-by: Honnappa Nagarahalli Reviewed-by: Gavin Hu Reviewed-by: Ola Liljedahl --- v2: * Fixed checkpatch warnings lib/librte_ring/rte_ring.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index d3d3f7f..2f9c945 100644 --- a/lib/librte_ring/rte_ring.h +++ b/lib/librte_ring/rte_ring.h @@ -26,8 +26,13 @@ * - Bulk dequeue. * - Bulk enqueue. * - * Note: the ring implementation is not preemptable. A lcore must not - * be interrupted by another task that uses the same ring. + * Note: the ring implementation can block threads from completing their + * operation under the following circumstances. + * A preempted thread can block other threads (operating on the same ring) + * from completing their operations, only if those threads are performing + * the same ring operation (enqueue/dequeue) as the preempted thread. + * In other words, a preempted consumer thread will not block any producer + * threads and vice versa. * */ -- 2.7.4