From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2019 10:25:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,507,1539673200"; d="scan'208";a="313870234" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga005.fm.intel.com with ESMTP; 22 Jan 2019 10:25:00 -0800 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 22 Jan 2019 10:25:00 -0800 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.99]) by FMSMSX119.amr.corp.intel.com ([169.254.14.102]) with mapi id 14.03.0415.000; Tue, 22 Jan 2019 10:25:00 -0800 From: "Eads, Gage" To: Thomas Monjalon CC: "dev@dpdk.org" , Honnappa Nagarahalli , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" , nd Thread-Topic: [dpdk-dev] [PATCH v4 2/2] mempool/nb_stack: add non-blocking stack mempool Thread-Index: AQHUrnqu5jX8tbxycUCltqyIk7tCgKWzwdxQgAGj7xCAAFADQIAAi4IAgAVeF/A= 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> In-Reply-To: <4946283.tQcWuvKPBh@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDJmZTFiNDMtNzYwMi00OTZjLWJlZTEtMmVlNWEwNzI1MDVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVFY5SWVXaVI5Z1I4VFAyamxXWTI3WmJnZGFoNmJYNkhrZlZtNThtQnJGQlRCRkwyY0QyZVwvTndZWFFWcHd1MSsifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 2/2] mempool/nb_stack: add non-blocking stack mempool 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, 22 Jan 2019 18:25:03 -0000 > -----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