From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 661DE1BB2C for ; Fri, 11 Jan 2019 20:55:23 +0100 (CET) Received: by mail-pg1-f196.google.com with SMTP id z11so6749449pgu.0 for ; Fri, 11 Jan 2019 11:55:23 -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=VTlYAZz8rTcj92LC4n/wlv0EwmJPzK1tQXDOikpGB9s=; b=aT88kQnparXSXEQ+gZNb6esIkd1QHMuKVme3sY3MGU9l4i1AQmjIObbFquz4aHKuWm bD+yRW1E64WLSs32OL5n5zkfMfa0PZTIyvnkvlQFHtU/oV73DXlw3Y+yZmT+2gAUpS5k xMVi82OdsccKjgQY5/Abo7y6y8C4NUA23gMHTp03I4LKC2b3cm/FRpYCAboHNP1eUHsg oLbHsrEgQqmLlzGSHe4Hzo/dMRHIyEGBnELMbWSF3Tff43ZjgcbttnpNFbJnNv8r7dA2 KfmIoowqAbSE9mq3qFfE505JLWslqcIFegLmSxCQ3jueqGrBjq0ScnCivaoOnr2MunyN Sejg== 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=VTlYAZz8rTcj92LC4n/wlv0EwmJPzK1tQXDOikpGB9s=; b=mPTp/B+OI0I+NlGxSrKfH1tD4R12kMbpTjbd7U0YNw2/Fz0U0Mt1lMUdnuisT2gdkz zkETnt3Hy1Agj/p+pmMU0NEiet9dymipGDDEsfLKHG0kmlz1QPINPLyVORTxEc5BJYJJ 91XVFBN2W0gL7RFPG7wLJAedR/099i5xU846Fh5NOxP95YQEINWcZK2Te9LIJmfdnpl5 6kQPgF2tfVyMOAelflvduJLc8lwSMpI8+Gr6rALEY9Kpi7MaLyEF6OC/xjbvg8cMcEzq vvaYPeKtIhDOsIv5lOSo8IL7+KigQytStJFOSdw8H070SBo1Jrygx0c5kjjEj7LqLZnA Uxcg== X-Gm-Message-State: AJcUukfj8SpDV1VJMVw0CVdUBk4MM0hYOj6yBWfwmGY21D5giBpfeBhG HltrCyprLKlnkQIjaTvO16L/RQ== X-Google-Smtp-Source: ALg8bN6Bnu4XPpeC9KJfYyzAQ7gvE2oQrvcRApa352tVycUEEhMzfZyz+N1VYmMOYrkY6feB3upTDg== X-Received: by 2002:a62:16d6:: with SMTP id 205mr15772984pfw.256.1547236522375; Fri, 11 Jan 2019 11:55:22 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id b2sm146055257pfm.3.2019.01.11.11.55.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 11 Jan 2019 11:55:22 -0800 (PST) Date: Fri, 11 Jan 2019 11:55:15 -0800 From: Stephen Hemminger To: "Eads, Gage" Cc: "Burakov, Anatoly" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" Message-ID: <20190111115515.524273ae@hermes.lan> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E541C4C3E@FMSMSX108.amr.corp.intel.com> References: <20190110210122.24889-1-gage.eads@intel.com> <20190110210122.24889-2-gage.eads@intel.com> <9184057F7FC11744A2107296B6B8EB1E541C4C3E@FMSMSX108.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size 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: Fri, 11 Jan 2019 19:55:23 -0000 On Fri, 11 Jan 2019 19:12:40 +0000 "Eads, Gage" wrote: > > -----Original Message----- > > From: Burakov, Anatoly > > Sent: Friday, January 11, 2019 4:25 AM > > To: Eads, Gage ; dev@dpdk.org > > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce > > ; Ananyev, Konstantin > > > > Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width > > size > > > > On 10-Jan-19 9:01 PM, Gage Eads wrote: > > > For 64-bit architectures, doubling the head and tail index widths > > > greatly increases the time it takes for them to wrap-around (with > > > current CPU speeds, it won't happen within the author's lifetime). > > > This is important in avoiding the ABA problem -- in which a thread > > > mistakes reading the same tail index in two accesses to mean that the > > > ring was not modified in the intervening time -- in the upcoming > > > non-blocking ring implementation. Using a 64-bit index makes the possibility of > > this occurring effectively zero. > > > > > > I tested this commit's performance impact with an x86_64 build on a > > > dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the change > > > made no significant difference -- the few differences appear to be system > > noise. > > > (The test ran on isolcpus cores using a tickless scheduler, but some > > > variation was stll observed.) Each test was run three times and the > > > results were averaged: > > > > > > | 64b head/tail cycle cost minus > > > Test | 32b head/tail cycle cost > > > ------------------------------------------------------------------ > > > SP/SC single enq/dequeue | 0.33 > > > MP/MC single enq/dequeue | 0.00 > > > SP/SC burst enq/dequeue (size 8) | 0.00 MP/MC burst enq/dequeue (size > > > 8) | 1.00 SP/SC burst enq/dequeue (size 32) | 0.00 MP/MC burst > > > enq/dequeue (size 32) | -1.00 > > > SC empty dequeue | 0.01 > > > MC empty dequeue | 0.00 > > > > > > Single lcore: > > > SP/SC bulk enq/dequeue (size 8) | -0.36 > > > MP/MC bulk enq/dequeue (size 8) | 0.99 > > > SP/SC bulk enq/dequeue (size 32) | -0.40 MP/MC bulk enq/dequeue (size > > > 32) | -0.57 > > > > > > Two physical cores: > > > SP/SC bulk enq/dequeue (size 8) | -0.49 > > > MP/MC bulk enq/dequeue (size 8) | 0.19 > > > SP/SC bulk enq/dequeue (size 32) | -0.28 MP/MC bulk enq/dequeue (size > > > 32) | -0.62 > > > > > > Two NUMA nodes: > > > SP/SC bulk enq/dequeue (size 8) | 3.25 > > > MP/MC bulk enq/dequeue (size 8) | 1.87 > > > SP/SC bulk enq/dequeue (size 32) | -0.44 MP/MC bulk enq/dequeue (size > > > 32) | -1.10 > > > > > > An earlier version of this patch changed the head and tail indexes to > > > uint64_t, but that caused a performance drop on 32-bit builds. With > > > uintptr_t, no performance difference is observed on an i686 build. > > > > > > Signed-off-by: Gage Eads > > > --- > > > > You're breaking the ABI - version bump for affected libraries is needed. > > > > -- > > Thanks, > > Anatoly > > If I'm reading the versioning guidelines correctly, I'll need to gate the changes with the RTE_NEXT_ABI macro and provide a deprecation notice, then after a full deprecation cycle we can revert that and bump the library version. Not to mention the 3 ML ACKs. > > I'll address this in v2. My understanding is that RTE_NEXT_API method is not used any more. Replaced by rte_experimental. But this kind of change is more of a flag day event. Which means it needs to be pushed off to a release that is planned as an ABI break (usually once a year) which would mean 19.11.