From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 356953B5 for ; Tue, 21 Mar 2017 15:45:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490107517; x=1521643517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8Pl6QfL4pmpSNMgIsxpbaJS3G2KtWlpz/MS3Lv9582I=; b=Ki+wI2pSYIJ+Cw6KcT3/SAcGsLZxASFhCBMCNVCWowlC/fPVxRq4Fddz 5nRIJmclpusyrPGcuLrD1B53lmP6bw==; Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 07:45:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,198,1486454400"; d="scan'208";a="63169434" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 21 Mar 2017 07:45:15 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 21 Mar 2017 07:45:15 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.175]) by fmsmsx115.amr.corp.intel.com ([169.254.4.3]) with mapi id 14.03.0319.002; Tue, 21 Mar 2017 07:45:15 -0700 From: "Wiles, Keith" To: Shreyansh Jain CC: "Hunt, David" , Olivier MATZ , DPDK , Thomas Monjalon , "hemant.agrawal@nxp.com" Thread-Topic: [PATCH 1/2] drivers/mempool: add stack mempool handler as driver Thread-Index: AQHSogs4LLL/FD1SIUO0zdO+M/m29KGf1MCA Date: Tue, 21 Mar 2017 14:45:13 +0000 Message-ID: <3328419E-C4DF-464B-AF4F-F73D7CC0179C@intel.com> References: <1490004190-16892-1-git-send-email-shreyansh.jain@nxp.com> <2fc176b1-a771-f4b5-a08d-1a31f46884d5@intel.com> <37546ac7-1c60-5992-5ebf-eef8e905017e@nxp.com> <70A6BC7D-3F07-4484-A8E4-ACB14522355B@intel.com> <43b90881-7fc7-8f75-f040-2ad8ea922333@nxp.com> In-Reply-To: <43b90881-7fc7-8f75-f040-2ad8ea922333@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.84.105] Content-Type: text/plain; charset="us-ascii" Content-ID: <995F347E9700784DB6D1D8BB21BD7853@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/2] drivers/mempool: add stack mempool handler as driver 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, 21 Mar 2017 14:45:17 -0000 > On Mar 21, 2017, at 1:25 AM, Shreyansh Jain wrot= e: >=20 > Hello Keith, >=20 > On Tuesday 21 March 2017 11:32 AM, Wiles, Keith wrote: >>=20 >>> On Mar 20, 2017, at 11:55 PM, Shreyansh Jain w= rote: >>>=20 >>> Hello David, >>>=20 >>> On Monday 20 March 2017 08:20 PM, Hunt, David wrote: >>>>=20 >>>> On 20/3/2017 10:03 AM, Shreyansh Jain wrote: >>>>> CONFIG_RTE_DRIVER_MEMPOOL_STACK option added to common_base. >>>>> Stack mempool handler moved from lib/librte_mempool into drivers/memp= ool. >>>>>=20 >>>=20 >>> <...> >>>=20 >>>>> -} >>>>> - >>>>> -static struct rte_mempool_ops ops_stack =3D { >>>>> - .name =3D "stack", >>>>> - .alloc =3D stack_alloc, >>>>> - .free =3D stack_free, >>>>> - .enqueue =3D stack_enqueue, >>>>> - .dequeue =3D stack_dequeue, >>>>> - .get_count =3D stack_get_count >>>>> -}; >>>>> - >>>>> -MEMPOOL_REGISTER_OPS(ops_stack); >>>>=20 >>>> Shreyansh, >>>> Could I suggest you add the parameter "--find-renames" when >>>> generating the patch files, as this will reduce the size of the patche= s >>>> significantly, making for easier review. The patch line count in this >>>> particular case would be reduced by approx 75%. >>>=20 >>> Thanks for suggestion. >>> Yes, I forgot to use this option while creating this patch. If there >>> are comments and v2 needs to be created, I will keep this in mind. >>>=20 >>>> Regards, >>>> Dave. >>=20 >> I guess I missed an email, but what is the advantage of moving the ring/= stack files to the drivers directory as they are not drivers in the sense o= f a NIC PMD or any other driver. You can still enable/disable them in the c= onfig files right? >>=20 >=20 > Just as reference, following is where this was being discussed: >=20 > http://dpdk.org/ml/archives/dev/2017-March/059690.html > http://dpdk.org/ml/archives/dev/2017-March/059753.html > and > http://dpdk.org/ml/archives/dev/2017-March/060501.html >=20 > Also, a while back (I can't trace that mailing list exchange), it was > decided that all mempool drivers (stack, ring, others...) would be > moved to drivers/mempool. >=20 > For NXP's DPAA2 PMD, we use an offloaded mempool for which there was a > patchset by Hemant [1] which adds that driver to drivers/mempool. In > the same breadth, ring and stack are also being moved to > drivers/mempool as independent drivers (non-offloaded category). >=20 > [1] http://dpdk.org/ml/archives/dev/2017-March/060476.html >=20 > In my opinion, this would make the lib/* area free of handler/drivers > (almost) and it is a good change. Also, ring and stack use a 'registratio= n' mechanism - just like PMD and are good candidate to be treated as 'drive= rs' now even though not entirely like a PMD. >=20 > You see any downside of this? OK, I am up to date now. The only downside is splitting the mempool code up= and making it a bit harder to manage, but it is a minor point. I do not se= e any stopper to prevent the change. Thanks. >=20 >> Regards, >> Keith >>=20 >>=20 >=20 > - > Shreyansh Regards, Keith