From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 403C8A00BE; Wed, 29 Apr 2020 11:04:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1BF8A1D993; Wed, 29 Apr 2020 11:04:08 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id AA1471D982 for ; Wed, 29 Apr 2020 11:04:03 +0200 (CEST) IronPort-SDR: kET1M5MBw5KhdnFplMV8x95opXqPg6sy+Th00tKajkOE95bbaXxvwJMEaD1qE47I4uCddGkTVv 0YV4KTmU/PaA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2020 02:04:02 -0700 IronPort-SDR: Q/yEhv4zA93tW5y0XAf7mRPKSajZahDeARJLp/Y/1ohoZ5yuPFBNqjAZ8IF5wjqANobmtvHodW i7ZV3+DHLCaQ== X-IronPort-AV: E=Sophos;i="5.73,331,1583222400"; d="scan'208";a="432492292" Received: from bricha3-mobl.ger.corp.intel.com ([10.249.47.131]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 29 Apr 2020 02:03:58 -0700 Date: Wed, 29 Apr 2020 10:03:54 +0100 From: Bruce Richardson To: "Dumitrescu, Cristian" Cc: Thomas Monjalon , Jerin Jacob , "Yigit, Ferruh" , Luca Boccassi , Nithin Dabilpuram , "Singh, Jasvinder" , Andrew Rybchenko , "dev@dpdk.org" , "jerinj@marvell.com" , "kkanas@marvell.com" , Nithin Dabilpuram , "Kinsella, Ray" , Neil Horman , Kevin Traynor , David Marchand Message-ID: <20200429090354.GA1903@bricha3-MOBL.ger.corp.intel.com> References: <20200330160019.29674-1-ndabilpuram@marvell.com> <20200428144535.GC1897@bricha3-MOBL.ger.corp.intel.com> <19c8b69f68bcdb7ac23126e63456223f7aff0465.camel@debian.org> <1923738.gORTcIGjah@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode 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" On Wed, Apr 29, 2020 at 09:45:44AM +0100, Dumitrescu, Cristian wrote: > > > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Tuesday, April 28, 2020 4:54 PM > > To: Jerin Jacob ; Dumitrescu, Cristian > > > > Cc: Richardson, Bruce ; Yigit, Ferruh > > ; Luca Boccassi ; Nithin > > Dabilpuram ; Singh, Jasvinder > > ; Andrew Rybchenko > > ; dev@dpdk.org; jerinj@marvell.com; > > kkanas@marvell.com; Nithin Dabilpuram ; > > Kinsella, Ray ; Neil Horman > > ; Kevin Traynor ; David > > Marchand > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add tm support for shaper > > config in pkt mode > > > > 28/04/2020 17:04, Luca Boccassi: > > > On Tue, 2020-04-28 at 15:45 +0100, Bruce Richardson wrote: > > > > On Tue, Apr 28, 2020 at 03:06:20PM +0100, Ferruh Yigit wrote: > > > > > On 4/27/2020 5:59 PM, Jerin Jacob wrote: > > > > > > On Mon, Apr 27, 2020 at 10:19 PM Ferruh Yigit > > wrote: > > > > > > > On 4/27/2020 5:29 PM, Jerin Jacob wrote: > > > > > > > > On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit > > wrote: > > > > > > > > > On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote: > > > > > > > > > > From: Yigit, Ferruh > > > > > > > > > > > On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote: > > > > > > > > > > > > From: Nithin Dabilpuram > > > > > > > > > > > > > This patch also updates tm port/level/node capability > > structures with > > > > > > > > > > > > > exiting features of scheduler wfq packet mode, > > scheduler wfq byte mode > > > > > > > > > > > > > and private/shared shaper byte mode. > > > > > > > > > > > > > > > > > > > > > > > > > > SoftNIC PMD is also updated with new capabilities. > > [...] > > > > > > > > > > > Hi Nithin, > > > > > > > > > > > > > > > > > > > > > > It looks like patch is causing ABI break, I am getting following > > warning [1], > > > > > > > > > > > can you please check? > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://pastebin.com/XYNFg14u > > > > > > > > > > > > > > > > > > > > Hi Ferruh, > > > > > > > > > > > > > > > > > > > > The RTE_TM API is marked as experimental, > > > > > > > > > > but it looks that this was not correctly marked > > > > > > > > > > when __rte_experimental ABI checker was introduced. > > > > > > > > > > > > > > > > > > > > It is marked as experimental at the top of the rte_tm.h, > > > > > > > > > > similarly to other APIs introduced around same time, > > > > > > > > > > but it was not correctly picked up by the ABI check procedure > > > > > > > > > > when later introduced, so __rte_experimental was not added > > to every function. > > > > > > > > > > > > > > > > > > > > > > > > > > > > :( > > > > > > > > > > > > > > > > > > Is it time to mature them? > > > > > > > > > > > > > > > > > > As you said they are not marked as experimental both in header > > file (function > > > > > > > > > declarations) and .map file. > > > > > > > > > > > > > > > > > > The problem is, they are not marked as experimental in > > DPDK_20.0 ABI (v19.11), > > > > > > > > > so marking them as experimental now will break the ABI. Not > > sure what to do, > > > > > > > > > cc'ed a few ABI related names for comment. > > > > > > > > > > > > > > > > > > For me, we need to proceed as the experimental tag removed > > and APIs become > > > > > > > > > mature starting from v19.11, since this is what happened in > > practice, and remove > > > > > > > > > a few existing being experimental references in the doxygen > > comments. > > > > > > > > > > > > > > > > I think, accidentally we can not make a library as NON- > > experimental. > > > > > > > > TM never went through experimental to mature transition(see git > > log > > > > > > > > lib/librte_ethdev/rte_tm.h) > > > > > > > > It was a bug to not mark as experimental in each function in the > > ABI process. > > > > > > > > Some of the features like packet marking are not even > > implemented by any HW. > > > > > > > > I think, we can make API stable only all the features are > > implemented > > > > > > > > by one or two HW. > > > > Yes this is what was decided one or two years ago I think. > > But rte_tm API was introduced 3 years ago and is implemented by 6 PMDs. > > > > > > > > > > > > > Fair enough, specially if the API is not ready yet. > > > > > > > > > > > > > > But they were part of stable ABI, and marking them as experimental > > now will > > > > > > > break the old applications using these APIs. > > > > > > > > > > > > it is still marked as EXPERIMENTAL everywhere and API is not ready > > yet. > > > > rte_tm is implemented in 6 PMDs. > > > > > > > > > Existing experimental marks are text only for human parsing. > > > > > > > > > > The compiler attribute and build time checks are missing, and the > > symbol in the > > > > > binary doesn't have experimental tag. Our scripts and automated > > checks won't > > > > > detect it as experimental. > > > > > > > > > > My point is just having experimental comment in header file is not > > enough to > > > > > qualify the APIs as experimental. > > > > > > > > > > > Anyway, we need to break the ABI to make it work on various HW. > > > > Yes this is why I was asking in 19.11 to check our API, > > in order to avoid such situation. > > > > > > > > > > I am not sure what to do? > > > > Either manage ABI versioning, or wait 20.11. > > > > > > > > > > IMO, We need to send a patch as Fixes: for the bug of not adding > > > > > > __rte_experimental in each function. > > > > No, this is wrong. > > > > Why exactly is this wrong? This is the gap that caused the current discussion, right? > It's wrong for this release, since we can't change things from stable back to experimental. Any such patch will have to wait for 20.11, as agreed in the discussion. /Bruce