From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 997B92BC1 for ; Mon, 13 May 2019 13:46:43 +0200 (CEST) Received: from lfbn-lil-1-768-100.w81-254.abo.wanadoo.fr ([81.254.99.100] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQ9SJ-0001aM-AG; Mon, 13 May 2019 13:49:20 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 13 May 2019 13:46:32 +0200 Date: Mon, 13 May 2019 13:46:32 +0200 From: Olivier Matz To: "Eads, Gage" Cc: Ola Liljedahl , "stephen@networkplumber.org" , "arybchenko@solarflare.com" , nd , "Ananyev, Konstantin" , "thomas@monjalon.net" , "Richardson, Bruce" , "dev@dpdk.org" , Honnappa Nagarahalli , "Gavin Hu (Arm Technology China)" Message-ID: <20190513114632.aems36zx5pbqk23n@platinum> References: <20190118153117.23810-1-gage.eads@intel.com> <20190201143623.31135-1-gage.eads@intel.com> <1845234.OyIqJ6yfKh@xps> <9184057F7FC11744A2107296B6B8EB1E68CB470E@fmsmsx101.amr.corp.intel.com> <20190510075855.2899716e@hermes.lan> <9184057F7FC11744A2107296B6B8EB1E68CB4A66@fmsmsx101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E68CB4A66@fmsmsx101.amr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change 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: Mon, 13 May 2019 11:46:43 -0000 On Fri, May 10, 2019 at 04:28:16PM +0000, Eads, Gage wrote: > > -----Original Message----- > > From: Ola Liljedahl [mailto:Ola.Liljedahl@arm.com] > > Sent: Friday, May 10, 2019 10:19 AM > > To: stephen@networkplumber.org; Eads, Gage > > Cc: arybchenko@solarflare.com; nd ; Ananyev, Konstantin > > ; thomas@monjalon.net; Richardson, > > Bruce ; dev@dpdk.org; > > olivier.matz@6wind.com; Honnappa Nagarahalli > > ; Gavin Hu (Arm Technology China) > > > > Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change > > > > On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote: > > > On Fri, 10 May 2019 14:53:56 +0000 > > > "Eads, Gage" wrote: > > > > > > 01/02/2019 15:36, Gage Eads: > > > In order to support the non-blocking ring[1], an API change > > > (additional argument to rte_ring_get_memsize()) is required in > > > librte_ring. This commit updates the deprecation notice to pave the > > > way for its inclusion in 19.08. > > > > > > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html > > > > > > Signed-off-by: Gage Eads > > > > > > There is still no agreement on this change? > > > > > > > > > Still none. I was hoping this discussion ( > > > http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead > > > to some clear direction, but at this point the effort is stalled. > > > > > > The fundamental tradeoff is between non-blocking rings and ABI breakage. > > > > It is also possible to do "non-blocking" (but not lock-free) rings with the > > original element size (a pointer per ring slot) as implemented here: > > https://github.com/ARM- > > software/progress64/blob/master/src/p64_ringbuf.c > > Some extra (head&tail) metadata is required but I think there is space for > > that in the rte_ring structure. > > > > > Why not have a new ring type for non-blocking rings since non-blocking > > > rings are not necessary for all use cases. > > > > I proposed a new library ("rte_lfring") with lock-free rings here: > > https://mails.dpdk.org/archives/dev/2019-January/124242.html > > The lock-free design should be the same as in Gage's patch. > > > > rte_lfring could of course be part of the rte_ring library. > > > > Just read through the API/ABI stability discussion > (https://mails.dpdk.org/archives/dev/2019-April/128969.html). I'll drop my > patchset and work on supporting this lfring API instead. +1 Given the discussions related to ABI stability, it looks better to implement this in another library. Olivier From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E9CF0A00E6 for ; Mon, 13 May 2019 13:46:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 07F2E2BCE; Mon, 13 May 2019 13:46:45 +0200 (CEST) Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 997B92BC1 for ; Mon, 13 May 2019 13:46:43 +0200 (CEST) Received: from lfbn-lil-1-768-100.w81-254.abo.wanadoo.fr ([81.254.99.100] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQ9SJ-0001aM-AG; Mon, 13 May 2019 13:49:20 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 13 May 2019 13:46:32 +0200 Date: Mon, 13 May 2019 13:46:32 +0200 From: Olivier Matz To: "Eads, Gage" Cc: Ola Liljedahl , "stephen@networkplumber.org" , "arybchenko@solarflare.com" , nd , "Ananyev, Konstantin" , "thomas@monjalon.net" , "Richardson, Bruce" , "dev@dpdk.org" , Honnappa Nagarahalli , "Gavin Hu (Arm Technology China)" Message-ID: <20190513114632.aems36zx5pbqk23n@platinum> References: <20190118153117.23810-1-gage.eads@intel.com> <20190201143623.31135-1-gage.eads@intel.com> <1845234.OyIqJ6yfKh@xps> <9184057F7FC11744A2107296B6B8EB1E68CB470E@fmsmsx101.amr.corp.intel.com> <20190510075855.2899716e@hermes.lan> <9184057F7FC11744A2107296B6B8EB1E68CB4A66@fmsmsx101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E68CB4A66@fmsmsx101.amr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change 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" Message-ID: <20190513114632.hT__qIK2lJyTbr2YXfpKiEth8O5Q0b3wF2nJcf9X0tA@z> On Fri, May 10, 2019 at 04:28:16PM +0000, Eads, Gage wrote: > > -----Original Message----- > > From: Ola Liljedahl [mailto:Ola.Liljedahl@arm.com] > > Sent: Friday, May 10, 2019 10:19 AM > > To: stephen@networkplumber.org; Eads, Gage > > Cc: arybchenko@solarflare.com; nd ; Ananyev, Konstantin > > ; thomas@monjalon.net; Richardson, > > Bruce ; dev@dpdk.org; > > olivier.matz@6wind.com; Honnappa Nagarahalli > > ; Gavin Hu (Arm Technology China) > > > > Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change > > > > On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote: > > > On Fri, 10 May 2019 14:53:56 +0000 > > > "Eads, Gage" wrote: > > > > > > 01/02/2019 15:36, Gage Eads: > > > In order to support the non-blocking ring[1], an API change > > > (additional argument to rte_ring_get_memsize()) is required in > > > librte_ring. This commit updates the deprecation notice to pave the > > > way for its inclusion in 19.08. > > > > > > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html > > > > > > Signed-off-by: Gage Eads > > > > > > There is still no agreement on this change? > > > > > > > > > Still none. I was hoping this discussion ( > > > http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead > > > to some clear direction, but at this point the effort is stalled. > > > > > > The fundamental tradeoff is between non-blocking rings and ABI breakage. > > > > It is also possible to do "non-blocking" (but not lock-free) rings with the > > original element size (a pointer per ring slot) as implemented here: > > https://github.com/ARM- > > software/progress64/blob/master/src/p64_ringbuf.c > > Some extra (head&tail) metadata is required but I think there is space for > > that in the rte_ring structure. > > > > > Why not have a new ring type for non-blocking rings since non-blocking > > > rings are not necessary for all use cases. > > > > I proposed a new library ("rte_lfring") with lock-free rings here: > > https://mails.dpdk.org/archives/dev/2019-January/124242.html > > The lock-free design should be the same as in Gage's patch. > > > > rte_lfring could of course be part of the rte_ring library. > > > > Just read through the API/ABI stability discussion > (https://mails.dpdk.org/archives/dev/2019-April/128969.html). I'll drop my > patchset and work on supporting this lfring API instead. +1 Given the discussions related to ABI stability, it looks better to implement this in another library. Olivier