From patchwork Tue Jul 10 04:00:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Honnappa Nagarahalli X-Patchwork-Id: 141505 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp3375187ljj; Mon, 9 Jul 2018 21:01:24 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf65Ag+B3kq95LFzjOT/dgtJkcdV3vvFjYwggHxPm14x3eiFaT4hrJh5bsSYDlpJYkfsDxq X-Received: by 2002:a1c:c40a:: with SMTP id u10-v6mr12897293wmf.10.1531195284672; Mon, 09 Jul 2018 21:01:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531195284; cv=none; d=google.com; s=arc-20160816; b=EMrt82EwZqB8u2P+mgXwvytZlbldzszjjHfJKlo0MC0QB++eqTjjWH/fulMRCY/RZn u6EJaHgvwL9vi+6HVuKcXgy8yevIzl9pDNEeXVTs+ONHzUfbC5QAxlvhjycubjdhtxFM tOt7kVlNj3JPib24vfyMatxnYmp9M7lsw7dZ1D4Hd6+BpC51rvkIoGYzoAUXMRisy22y SAbTC2353qoZHIl4Qx22EJgYPnI6uFrBHDO0zmm3oBuTVjwPMGyfW0qtFQqX0KypQ3tS bi3hLNPXCqmJuhMDd5w+q2fcYLEsyn2jCDIeOrWd3uK4epDYc8H7LjPSoqlA9tg/CECR ap/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject:message-id:date:cc:to :from:arc-authentication-results; bh=EJVTSKI3LXSvw8wpQjjSBSk4YnI2GqZXLA7PjSxXO2c=; b=ngzvDs3RIVvPof3Wq6hrns/Yg6B+08u9uAXjloZKVSQJWolQIXvLV8JgqaPnjMmf5q qEIM/xzedIi8a1YX0MO6+T/pZla4P8rjFbx2slvxni2bQshkTUeuXnhWa2PiBSDsPCb5 cnPi/4eF2e47enJSTW4X5la4N8A+hLMyL9isSzmXAuhbqkdrft4DWV6+BdqqPrsOUxzN EUBXU6qgC+tXHnCbuhu04tm5DqTDRP6rz5GwVh5+KaBmZ2TuWnA19fIgYhqQg9yIxgB2 269p0cTpwBhQ4t6xRwv88b6sP8MPWr8ccxVPt8748DPhlTlqaY+WiIIPRIF4soJCL7ez UESQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of dev-bounces@dpdk.org designates 92.243.14.124 as permitted sender) smtp.mailfrom=dev-bounces@dpdk.org Return-Path: Received: from dpdk.org (dpdk.org. [92.243.14.124]) by mx.google.com with ESMTP id u4-v6si14940227wrc.278.2018.07.09.21.01.24; Mon, 09 Jul 2018 21:01:24 -0700 (PDT) Received-SPF: pass (google.com: domain of dev-bounces@dpdk.org designates 92.243.14.124 as permitted sender) client-ip=92.243.14.124; Authentication-Results: mx.google.com; spf=pass (google.com: domain of dev-bounces@dpdk.org designates 92.243.14.124 as permitted sender) smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B7FD45911; Tue, 10 Jul 2018 06:01:22 +0200 (CEST) Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by dpdk.org (Postfix) with ESMTP id 4B4D1559A for ; Tue, 10 Jul 2018 06:01:21 +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 6213F7A9; Mon, 9 Jul 2018 21:01:20 -0700 (PDT) Received: from ubuntu.localdomain (unknown [10.119.48.90]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C37043F5A0; Mon, 9 Jul 2018 21:01:19 -0700 (PDT) From: Honnappa Nagarahalli To: honnappa.nagarahalli@arm.com, anatoly.burakov@intel.com, olivier.matz@6wind.com Cc: dev@dpdk.org, nd@arm.com Date: Mon, 9 Jul 2018 23:00:47 -0500 Message-Id: <1531195247-22612-1-git-send-email-honnappa.nagarahalli@arm.com> X-Mailer: git-send-email 2.7.4 Subject: [dpdk-dev] [PATCH v3] 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 --- v3: * Corrected known issues for rte_ring * Referred to known issues in rte_ring.h (Burakov, Oliver) v2: * Fixed checkpatch warnings doc/guides/prog_guide/env_abstraction_layer.rst | 27 ++++++++++++++----------- lib/librte_ring/rte_ring.h | 5 +++-- 2 files changed, 18 insertions(+), 14 deletions(-) -- 2.7.4 diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index a22640d..f47a4be 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -435,23 +435,26 @@ Known Issues The "non-preemptive" constraint means: - - a pthread doing multi-producers enqueues on a given ring must not - be preempted by another pthread doing a multi-producer enqueue on - the same ring. - - a pthread doing multi-consumers dequeues on a given ring must not - be preempted by another pthread doing a multi-consumer dequeue on - the same ring. + A preempted pthread can block other pthreads (operating on the same ring) + from completing their operations, only if those pthreads are performing + the same ring operation (enqueue/dequeue) as the preempted pthread. + In other words, a preempted consumer pthread will not block any producer + pthreads and vice versa. - Bypassing this constraint may cause the 2nd pthread to spin until the 1st one is scheduled again. - Moreover, if the 1st pthread is preempted by a context that has an higher priority, it may even cause a dead lock. + Bypassing this constraint may cause other pthreads to spin until the preempted pthread is scheduled again. + Moreover, if the pthread is preempted by a context that has a higher priority, it may even cause a dead lock. - This does not mean it cannot be used, simply, there is a need to narrow down the situation when it is used by multi-pthread on the same core. + This means, use cases involving preemptible pthreads should consider using rte_ring carefully. - 1. It CAN be used for any single-producer or single-consumer situation. + 1. It CAN be used for preemptible single-producer and single-consumer use case. - 2. It MAY be used by multi-producer/consumer pthread whose scheduling policy are all SCHED_OTHER(cfs). User SHOULD be aware of the performance penalty before using it. + 2. It CAN be used for non-preemptible multi-producer and preemptible single-consumer use case. - 3. It MUST not be used by multi-producer/consumer pthreads, whose scheduling policies are SCHED_FIFO or SCHED_RR. + 3. It CAN be used for preemptible single-producer and non-preemptible multi-consumer use case. + + 4. It MAY be used by preemptible multi-producer and/or preemptible multi-consumer pthreads whose scheduling policy are all SCHED_OTHER(cfs), SCHED_IDLE or SCHED_BATCH. User SHOULD be aware of the performance penalty before using it. + + 5. It MUST not be used by multi-producer/consumer pthreads, whose scheduling policies are SCHED_FIFO or SCHED_RR. + rte_timer diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index 1245822..e680101 100644 --- a/lib/librte_ring/rte_ring.h +++ b/lib/librte_ring/rte_ring.h @@ -26,8 +26,9 @@ * - 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 is not preemptible. Refer to Programmer's + * guide/Environment Abstraction Layer/Multiple pthread/Known Issues/rte_ring + * for more information. * */