From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A743D326C for ; Tue, 15 Jan 2019 16:48:47 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2019 07:48:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,481,1539673200"; d="scan'208";a="127953154" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 15 Jan 2019 07:48:46 -0800 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 15 Jan 2019 07:48:46 -0800 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.99]) by fmsmsx156.amr.corp.intel.com ([169.254.13.179]) with mapi id 14.03.0415.000; Tue, 15 Jan 2019 07:48:46 -0800 From: "Eads, Gage" To: Stephen Hemminger CC: "Burakov, Anatoly" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size Thread-Index: AQHUqZf3SGNAhgPQUEq3X66uBo4z+qWqbrvAgACTVYCABXo2EA== Date: Tue, 15 Jan 2019 15:48:45 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E541C71B3@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> <20190111115515.524273ae@hermes.lan> In-Reply-To: <20190111115515.524273ae@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDkzOThlZDEtYWYzMy00NGMzLThlNmUtNzUzZTY4YWFjNmI5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTUtVbWZJUFFqbTZxRzd3bDg0WVBmaFg4bnAzZ3dJK0V5eWJGc2ZKUWM5M3dLc1BKMGFjemZVY1dmZ2Z4a3VMNCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.1.200.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 15 Jan 2019 15:48:48 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Friday, January 11, 2019 1:55 PM > To: Eads, Gage > Cc: Burakov, Anatoly ; dev@dpdk.org; > 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 >=20 > On Fri, 11 Jan 2019 19:12:40 +0000 > "Eads, Gage" wrote: >=20 > > > -----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 bu= ild. > > > > > > > > Signed-off-by: Gage Eads > > > > --- > > > > > > You're breaking the ABI - version bump for affected libraries is need= ed. > > > > > > -- > > > Thanks, > > > Anatoly > > > > If I'm reading the versioning guidelines correctly, I'll need to gate t= he 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. N= ot to > mention the 3 ML ACKs. > > > > I'll address this in v2. >=20 > My understanding is that RTE_NEXT_API method is not used any more. Replac= ed > 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 y= ear) > which would mean 19.11. In recent release notes, I see ABI changes can happen more frequently than = once per year; 18.11, 18.05, 17.11, and 17.08 have ABI changes -- and soon = 19.02 will too. At any rate, I'll create a separate deprecation notice patch and update thi= s patchset accordingly. Thanks, Gage