From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eads, Gage" Subject: Re: [PATCH v4 2/2] mempool/nb_stack: add non-blocking stack mempool Date: Tue, 22 Jan 2019 18:24:59 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E541CA2D2@FMSMSX108.amr.corp.intel.com> References: <20190116151835.22424-1-gage.eads@intel.com> <9184057F7FC11744A2107296B6B8EB1E541C9612@FMSMSX108.amr.corp.intel.com> <4946283.tQcWuvKPBh@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , Honnappa Nagarahalli , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" , nd To: Thomas Monjalon Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id D154625D9 for ; Tue, 22 Jan 2019 19:25:02 +0100 (CET) In-Reply-To: <4946283.tQcWuvKPBh@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Friday, January 18, 2019 6:15 PM > To: Eads, Gage > Cc: dev@dpdk.org; Honnappa Nagarahalli ; > olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce > ; Ananyev, Konstantin > ; Gavin Hu (Arm Technology China) > ; nd > Subject: Re: [dpdk-dev] [PATCH v4 2/2] mempool/nb_stack: add non-blocking > stack mempool >=20 > 19/01/2019 01:00, Eads, Gage: > > > > I am wondering if it makes sense to decouple the NB stack data > > > > structure from mempool driver (similar to rte_ring)? I see that > > > > stack based mempool implements the stack data structure in the > > > > driver. But, NB stack might not be such a trivial data structure. > > > > It might be useful for the applications or other use cases as well. > > > > > > > > > > I agree -- and you're not the first to suggest this :). > > > > > > I'm going to defer that work to a later patchset; creating a new > > > lib/ directory requires tech board approval (IIRC), which would > > > unnecessarily slow down this mempool handler from getting merged. >=20 > You have time. This patch cannot go in 19.02. > You just need to be ready for 19.05-rc1 (more than 2 months). >=20 Understood, I was concerned the process could take longer. The code itself = isn't too complicated, but I'm not sure how much time it'll take to reach c= onsensus on the interface. On the other hand, it may go quickly if we model= it after the ring API -- my current thinking -- which folks seem to genera= lly like. Anyway, I'll rework this into a standalone stack library. Thanks, Gage > [...] > > modularizing nb_lifo can be deferred to the patchset that moves it to a > separate library. >=20 > Please introduce it in the right place from the beginning. >=20