From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v2 0/5] Add non-blocking ring Date: Tue, 15 Jan 2019 16:26:27 -0800 Message-ID: <20190115162627.4219d405@shemminger-XPS-13-9360> References: <20190110210122.24889-1-gage.eads@intel.com> <20190115235227.14013-1-gage.eads@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, olivier.matz@6wind.com, arybchenko@solarflare.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com To: Gage Eads Return-path: Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by dpdk.org (Postfix) with ESMTP id 960AD239 for ; Wed, 16 Jan 2019 01:26:30 +0100 (CET) Received: by mail-pg1-f193.google.com with SMTP id s198so1976367pgs.2 for ; Tue, 15 Jan 2019 16:26:30 -0800 (PST) In-Reply-To: <20190115235227.14013-1-gage.eads@intel.com> 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 Tue, 15 Jan 2019 17:52:22 -0600 Gage Eads wrote: > For some users, the rte ring's "non-preemptive" constraint is not acceptable; > for example, if the application uses a mixture of pinned high-priority threads > and multiplexed low-priority threads that share a mempool. > > This patchset introduces a non-blocking ring, on top of which a mempool can run. > Crucially, the non-blocking algorithm relies on a 128-bit compare-and-swap, so > it is limited to x86_64 machines. > > The ring uses more compare-and-swap atomic operations than the regular rte ring: > With no contention, an enqueue of n pointers uses (1 + 2n) CAS operations and a > dequeue of n pointers uses 2. This algorithm has worse average-case performance > than the regular rte ring (particularly a highly-contended ring with large bulk > accesses), however: > - For applications with preemptible pthreads, the regular rte ring's worst-case > performance (i.e. one thread being preempted in the update_tail() critical > section) is much worse than the non-blocking ring's. > - Software caching can mitigate the average case performance for ring-based > algorithms. For example, a non-blocking ring based mempool (a likely use case > for this ring) with per-thread caching. > > The non-blocking ring is enabled via a new flag, RING_F_NB. For ease-of-use, > existing ring enqueue/dequeue functions work with both "regular" and > non-blocking rings. > > This patchset also adds non-blocking versions of ring_autotest and > ring_perf_autotest, and a non-blocking ring based mempool. > > This patchset makes ABI and API changes; a deprecation notice will be > posted in a separate commit. > > This patchset depends on the non-blocking stack patchset[1]. > > [1] http://mails.dpdk.org/archives/dev/2019-January/123470.html > > v2: > - Merge separate docs commit into patch #5 > - Convert uintptr_t to size_t > - Add a compile-time check for the size of size_t > - Fix a space-after-typecast issue > - Fix an unnecessary-parentheses checkpatch warning > - Bump librte_ring's library version > > Gage Eads (5): > ring: change head and tail to pointer-width size > ring: add a non-blocking implementation > test_ring: add non-blocking ring autotest > test_ring_perf: add non-blocking ring perf test > mempool/ring: add non-blocking ring handlers > > doc/guides/prog_guide/env_abstraction_layer.rst | 2 +- > drivers/mempool/ring/rte_mempool_ring.c | 58 ++- > lib/librte_eventdev/rte_event_ring.h | 6 +- > lib/librte_ring/Makefile | 2 +- > lib/librte_ring/meson.build | 2 +- > lib/librte_ring/rte_ring.c | 53 ++- > lib/librte_ring/rte_ring.h | 564 ++++++++++++++++++++++-- > lib/librte_ring/rte_ring_generic.h | 16 +- > lib/librte_ring/rte_ring_version.map | 7 + > test/test/test_ring.c | 57 ++- > test/test/test_ring_perf.c | 19 +- > 11 files changed, 699 insertions(+), 87 deletions(-) > Just bumping the version number is not enough. This looks like an ABI breakage for existing users.