From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id DB63358CB for ; Mon, 10 Jul 2017 15:21:24 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2017 06:21:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,340,1496127600"; d="scan'208";a="1193561544" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 10 Jul 2017 06:21:22 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX101.ger.corp.intel.com ([169.254.1.242]) with mapi id 14.03.0319.002; Mon, 10 Jul 2017 14:21:21 +0100 From: "Dumitrescu, Cristian" To: Thomas Monjalon CC: "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "Singh, Jasvinder" , "Lu, Wenzhuo" , "O'Driscoll, Tim" , "Glynn, Michael J" , Adrien Mazarguil Thread-Topic: [dpdk-dev] [pull-request] next-tm 17.08 pre-rc1 Thread-Index: AQHS9NvD1n6mRK62C0yv42q5/ePxaaJL4dWAgAD3fpCAACRYAIAAFwzA Date: Mon, 10 Jul 2017 13:21:20 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BA7D90C@IRSMSX108.ger.corp.intel.com> References: <1499182731-86830-1-git-send-email-cristian.dumitrescu@intel.com> <1838852.sCttUoyffy@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA7D62D@IRSMSX108.ger.corp.intel.com> <6030891.m1QB3o9leh@xps> In-Reply-To: <6030891.m1QB3o9leh@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmUyYjEwYzUtNDQ5MS00NDBkLWJiODMtM2FlOGFmOGY2YWQxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IldJWDFhVkJYQ1JqUDExQzVjVVZzTDVWZFpWVnhGTlBXY1d2NXQ5M1lPYk09In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [pull-request] next-tm 17.08 pre-rc1 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, 10 Jul 2017 13:21:25 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Monday, July 10, 2017 1:57 PM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; > hemant.agrawal@nxp.com; Singh, Jasvinder ; > Lu, Wenzhuo ; O'Driscoll, Tim > ; Glynn, Michael J ; > Adrien Mazarguil > Subject: Re: [dpdk-dev] [pull-request] next-tm 17.08 pre-rc1 >=20 > Hi, >=20 > 10/07/2017 12:55, Dumitrescu, Cristian: > > Hi Thomas, > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > Hi, > > > > > > 04/07/2017 17:38, Cristian Dumitrescu: > > > > http://dpdk.org/git/next/dpdk-next-tm > > > > > > I'm sorry to not have considered this tree as a high priority. > > > I think it may be integrated in RC2 because it is a totally new area > > > and should not break any existing code. > > > > > > I prefer to wait because I have seen some things to fix: > > > > > > 1/ There is a compilation error with clang (notified in related threa= d). > > > > Thanks for sending the error log, looks simple to fix, we will fix this= ASAP. > > > > > 2/ Some functions are exposed in the API to query the ops. > > > It seems dangerous and useless: > > > - rte_eth_dev_tm_ops_get > > > - rte_tm_ops_get > > > > Thomas, hopefully this is a misunderstanding on your side :(((. >=20 > Don't worry :) >=20 > > This is a critical point that we debated ad nauseam on this email list = (RFC, V1 > -V6) and privately as well. You were included in the conversation, you al= so > provided feed-back that we incorporated in the code, as documented in the > patchset history log. > > > > This is simply the mechanism that we (including you) agreed to use for > modularizing the DPDK ethdev by adding new functionality in a modular plu= g- > in way using separate namespace. This is the exact clone of the same > mechanism that rte_flow is using and was merged in DPDK release 17.02. > Why this change on the fundamentals now? > > > > Hopefully, it is just misunderstanding. >=20 > I mean that only the drivers need to get the ops. > The applications are using some dedicated functions rte_tm_* , right? > So the applications does not need direct ops access with > rte_eth_dev_tm_ops_get()? > Sorry if it is my misunderstanding. >=20 > About rte_tm_ops_get, I don't remember why I talked about it. > It seems exposed only to drivers. My mistake. No issue there. >=20 OK, so we're good then? > > > 3/ The PMD interface file is referenced in the doxygen index: > > > + [rte_tm_driver] (@ref rte_tm_driver.h), > > > I see that rte_flow_driver.h is also referenced but it seems a mistak= e. > > > > We simply followed the rte_flow precedent. We will remove this line. > > > > > 4/ As it is a totally new API, it should be declared as EXPERIMENTAL > > > in the MAINTAINERS file and in the doxygen. > > > > We can add the EXPERIMENTAL tag for this API in the MANTAINERS file and > at the top of the API file for DPDK release 17.08. Is this OK with you? >=20 > Yes, perfect. >=20 > > But, as Jerin also asked at the time when eventdev API was introduced, > what is the process to remove the EXPERIMENTAL label? Do you agree that > we can remove the experimental label in the next release 17.11? >=20 > Yes I think it is reasonnable. >=20 > > IMO it makes sense to mark new APIs as experimental for some time, it > should be very clear when this label can be removed. We had examples of > customers being confused by this label and questioning us whether they > should use such APIs or not, therefore the process or applying & removing > this label should be clearly documented, which right now it is not at all= . >=20 > The idea is to highlight that it is a new API and may be not stable enoug= h. > The question is when do we know it is mature enough? > I don't know and I guess it is up to the maintainer of the API. > Please remind that after removing the EXPERIMENTAL status, you must > follow > the API deprecation status. >=20 > > To this moment, this was not followed consistently in DPDK either. Rece= nt > examples: > > 1. rte_flow API, introduced in DPDK release 17.02 was never marked as > EXPERIMENTAL in either MANTAINERS or API file > > 2. eventdev API, introduced in DPDK release 17.05, was marked as > EXPERIMENTAL in the MAINTAINERS file, but not in the API file >=20 > Yes, not perfect ;) >=20 > > > 5/ There is no doc in the programmer's guide. > > > > We are definitely going to add comprehensive documentation for this new > API before the 17.08 documentation deadline. Is this OK with you? >=20 > Yes, good to know. >=20 > > As a precedent, eventdev API was introduced in 17.05 with test applicat= ion > just added now (one release later). > > > > > 6/ There is no application to test it. > > > > Yes, we will either extend test-pmd or add a new example application to > exercise this API for next DPDK release 17.11. CC-ing Tim and Mike to > confirm. >=20 > Yes I think it would be important to have it in 17.11. >=20 > > > I know that the points 5/ and 6/ are long to complete. > > > However I would like to know what is the plan? > > > And should we integrate TM in 17.08 without neither doc nor app? > > > > As stated above, we are going to add documentation for this new API on > this release and test application in the next release. >=20 > OK looks a good plan. > Please be aware that the documentation must be submitted in two weeks > to let us few days for reviewing.