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 7BA19A0524; Mon, 24 Feb 2020 17:59:29 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D9D671BE85; Mon, 24 Feb 2020 17:59:28 +0100 (CET) Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by dpdk.org (Postfix) with ESMTP id 237CB1F1C for ; Mon, 24 Feb 2020 17:59:28 +0100 (CET) Received: by mail-pl1-f195.google.com with SMTP id d9so4280604plo.11 for ; Mon, 24 Feb 2020 08:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=eYCzi4F7cow9LH8wOhvHTmX3CS7fxCcp+ryVPQwDI+o=; b=s68kZQbFSZ2uQi25Hp+hbed1qK7JQgIWvt3AQFZ0lVl0kKsu/D3EwVEflWmhGO8fBK jPZQlz/J1XsAG6q438pN5aw9M4LbkBKUxpHbfoOk0S2genPggBjdIJGvfsaeWG0tDMQN k8PH7f+Z5KU8Kpcen22cyaJz65TZAZS4PUVW0AGbT5hozxu+Le7CDuIjnZDFgATWBrW2 eqD/M9x2dQ54OGTjfyqlRZgzdX3ZMsmLJ7PfKJSa/tQ4vsxXI1LJ7elOVwYTL6vyFSrH LfhOv12QZKVq1wiFHsTk6CfDH+D8a9CE1w3KzVbqL8hrRjqYediEowXectEDTusbmN+i 1g2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=eYCzi4F7cow9LH8wOhvHTmX3CS7fxCcp+ryVPQwDI+o=; b=IJmWE9ZkHrDN0X6hJkIGsUur09EuPpZ2RSRe6awvFTbSBwmGkG0VVnb4g74RDtvwwN ikAhx/tI3FQczkv1sIU2xkRKoA0BMSzGJAeYUxfDgnqqm2k4/VDzzEhr7G6jSGlgLTXF zIbTMtXW+OgIUHbLu++Ai6VVEBx0Uk3qMVO28VHxEz6LS0ve+CBsK90uS91UJ7Vj8YCX kpnmvVl/21o44GTdHdrvhqCqSFYOXimyIxbfFQg8/IXzultuPJRg5IBS/19Now287GiM 9XL8jP5LW8bD3xVTlKOyXEQDM3LUmOZUASJaUZWpDJ5PPQtD2sr8aWJ66wxBAISgZkDB DFEg== X-Gm-Message-State: APjAAAW8BjX37p+5tn4fEZNgprsSc4DoaWDTjroItZK7MWzcofVqKoWX YW32z2CyPy0BQ/7YhczlvNJZ4A== X-Google-Smtp-Source: APXvYqwiTjDhjEx9gvEgi9NObcajRs3qjEAHW95X/dZ1LWAr9PNmYgIomMY2M+pqWCeK4c6bvP3tCQ== X-Received: by 2002:a17:902:d216:: with SMTP id t22mr50445267ply.150.1582563567298; Mon, 24 Feb 2020 08:59:27 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id f3sm12971849pga.38.2020.02.24.08.59.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 08:59:27 -0800 (PST) Date: Mon, 24 Feb 2020 08:59:19 -0800 From: Stephen Hemminger To: Konstantin Ananyev Cc: dev@dpdk.org, olivier.matz@6wind.com Message-ID: <20200224085919.3e73fda7@hermes.lan> In-Reply-To: <20200224113515.1744-1-konstantin.ananyev@intel.com> References: <20200224113515.1744-1-konstantin.ananyev@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/6] New sync modes for ring 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 Mon, 24 Feb 2020 11:35:09 +0000 Konstantin Ananyev wrote: > Upfront note - that RFC is not a complete patch. > It introduces an ABI breakage, plus it doesn't update ring_elem > code properly, etc. > I plan to deal with all these things in later versions. > Right now I seek an initial feedback about proposed ideas. > Would also ask people to repeat performance tests (see below) > on their platforms to confirm the impact. > > More and more customers use(/try to use) DPDK based apps within > overcommitted systems (multiple acttive threads over same pysical cores): > VM, container deployments, etc. > One quite common problem they hit: Lock-Holder-Preemption with rte_ring. > LHP is quite a common problem for spin-based sync primitives > (spin-locks, etc.) on overcommitted systems. > The situation gets much worse when some sort of > fair-locking technique is used (ticket-lock, etc.). > As now not only lock-owner but also lock-waiters scheduling > order matters a lot. > This is a well-known problem for kernel within VMs: > http://www-archive.xenproject.org/files/xensummitboston08/LHP.pdf > https://www.cs.hs-rm.de/~kaiser/events/wamos2017/Slides/selcuk.pdf > The problem with rte_ring is that while head accusion is sort of > un-fair locking, waiting on tail is very similar to ticket lock schema - > tail has to be updated in particular order. > That makes current rte_ring implementation to perform > really pure on some overcommited scenarios. Rather than reform rte_ring to fit this scenario, it would make more sense to me to introduce another primitive. The current lockless ring performs very well for the isolated thread model that DPDK was built around. This looks like a case of customers violating the usage model of the DPDK and then being surprised at the fallout.