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 E9E34A00BE; Tue, 28 Apr 2020 17:04:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 152B71D60B; Tue, 28 Apr 2020 17:04:44 +0200 (CEST) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 675611D605 for ; Tue, 28 Apr 2020 17:04:43 +0200 (CEST) Received: by mail-wr1-f67.google.com with SMTP id j2so25047998wrs.9 for ; Tue, 28 Apr 2020 08:04:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=a94bvCKidcboFWnGQK2DlYqm/EaMxGbzvEaTAuN878k=; b=O4H1T59VgWzIztPcrxgEwiSYNA2ohG760p/JNb4tZ79QkjrRfEgV/XwTaQIsu6rfEM PlJ+zkISEzPCvb3wSWD1Q7OrV0rCOoql4mhBYCum/7nSjdsdrRogKn9OCMAbTAuuWpbE bTYviVn/JAnl/Tahb1DGiRJAnbPe2cfv5BRcJnLk1MVQPQ/QcOAsiwe9rzM/Q5ifQkeg T8UlcOU/juJOTdigVgRFOf8t0LTcYsTvZpn71z5vCbtzfp6PDL+w1jBFKCkTrZNClqTk +oy6IRV9vb7uhQ5O2TFUMGyG+LM51AsBFkU2CAnjTSGp8CbW2n4kFTrXN99hsGCI9sN6 MwkA== X-Gm-Message-State: AGi0PuYt6u2tDTyW9lDm80TRSQTzAsfxZEZhzRJo+nZKzGxOMjzo05D4 ybNuE+egHMBhMRj/VgTmxaE= X-Google-Smtp-Source: APiQypJQf3TfR/OmpMdTrEKs7UQkRwX8lV+7Wbq7bbKxGrYo7x6faNTxSHpxZWZE/NuutV+6TAG5QA== X-Received: by 2002:a5d:4109:: with SMTP id l9mr33817092wrp.300.1588086282964; Tue, 28 Apr 2020 08:04:42 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:7a8e:ed70:5c52:ea3]) by smtp.gmail.com with ESMTPSA id b2sm27998990wrn.6.2020.04.28.08.04.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 08:04:41 -0700 (PDT) Message-ID: <19c8b69f68bcdb7ac23126e63456223f7aff0465.camel@debian.org> From: Luca Boccassi To: Bruce Richardson , Ferruh Yigit Cc: Jerin Jacob , "Dumitrescu, Cristian" , Nithin Dabilpuram , "Singh, Jasvinder" , Thomas Monjalon , Andrew Rybchenko , "dev@dpdk.org" , "jerinj@marvell.com" , "kkanas@marvell.com" , Nithin Dabilpuram , "Kinsella, Ray" , Neil Horman , Kevin Traynor , David Marchand Date: Tue, 28 Apr 2020 16:04:40 +0100 In-Reply-To: <20200428144535.GC1897@bricha3-MOBL.ger.corp.intel.com> References: <20200330160019.29674-1-ndabilpuram@marvell.com> <20200422172104.23099-1-nithind1988@gmail.com> <3f14bb70-b963-437d-9451-ccee3b100915@intel.com> <20200428144535.GC1897@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 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 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: > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Yigit, Ferruh > > > > > > > > Sent: Saturday, April 25, 2020 9:09 PM > > > > > > > > To: Dumitrescu, Cristian ; N= ithin Dabilpuram > > > > > > > > ; Singh, Jasvinder ; > > > > > > > > Thomas Monjalon ; Andrew Rybchenko > > > > > > > > > > > > > > > > Cc: dev@dpdk.org; jerinj@marvell.com; kkanas@marvell.com; N= ithin > > > > > > > > Dabilpuram > > > > > > > > Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shap= er config in pkt > > > > > > > > mode > > > > > > > >=20 > > > > > > > > On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote: > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Nithin Dabilpuram > > > > > > > > > > Sent: Wednesday, April 22, 2020 6:21 PM > > > > > > > > > > To: Singh, Jasvinder ; Dumit= rescu, Cristian > > > > > > > > > > ; Thomas Monjalon > > > > > > > > > > ; Yigit, Ferruh ; Andrew > > > > > > > > > > Rybchenko > > > > > > > > > > Cc: dev@dpdk.org; jerinj@marvell.com; kkanas@marvell.co= m; Nithin > > > > > > > > > > Dabilpuram > > > > > > > > > > Subject: [PATCH v4 1/4] ethdev: add tm support for shap= er config in pkt > > > > > > > > > > mode > > > > > > > > > >=20 > > > > > > > > > > From: Nithin Dabilpuram > > > > > > > > > >=20 > > > > > > > > > > Some NIC hardware support shaper to work in packet mode= i.e > > > > > > > > > > shaping or ratelimiting traffic is in packets per secon= d (PPS) as > > > > > > > > > > opposed to default bytes per second (BPS). Hence this p= atch > > > > > > > > > > adds support to configure shared or private shaper in p= acket mode, > > > > > > > > > > provide rate in PPS and add related tm capabilities in = port/level/node > > > > > > > > > > capability structures. > > > > > > > > > >=20 > > > > > > > > > > This patch also updates tm port/level/node capability s= tructures with > > > > > > > > > > exiting features of scheduler wfq packet mode, schedule= r wfq byte mode > > > > > > > > > > and private/shared shaper byte mode. > > > > > > > > > >=20 > > > > > > > > > > SoftNIC PMD is also updated with new capabilities. > > > > > > > > > >=20 > > > > > > > > > > Signed-off-by: Nithin Dabilpuram > > > > > > > > > > --- > > > > > > > > > > v3..v4: > > > > > > > > > > - Update text under packet_mode as per Cristian. > > > > > > > > > > - Update rte_eth_softnic_tm.c based on Jasvinder's comm= ents. > > > > > > > > > > - Add error enum > > > > > > > > RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE > > > > > > > > > > - Fix shaper_profile_check() with packet mode check > > > > > > > > > > - Fix typo's > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Acked-by: Cristian Dumitrescu > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi Nithin, > > > > > > > >=20 > > > > > > > > It looks like patch is causing ABI break, I am getting foll= owing warning [1], > > > > > > > > can you please check? > > > > > > > >=20 > > > > > > > > [1] > > > > > > > > https://pastebin.com/XYNFg14u > > > > > > >=20 > > > > > > > Hi Ferruh, > > > > > > >=20 > > > > > > > The RTE_TM API is marked as experimental, but it looks that t= his was not correctly marked when __rte_experimental ABI checker was introd= uced. > > > > > > >=20 > > > > > > > It is marked as experimental at the top of the rte_tm.h, simi= larly to other APIs introduced around same time, but it was not correctly p= icked up by the ABI check procedure when later introduced, so __rte_experim= ental was not added to every function. > > > > > > >=20 > > > > > >=20 > > > > > > :( > > > > > >=20 > > > > > > Is it time to mature them? > > > > > >=20 > > > > > > As you said they are not marked as experimental both in header = file (function > > > > > > declarations) and .map file. > > > > > >=20 > > > > > > 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 sur= e what to do, > > > > > > cc'ed a few ABI related names for comment. > > > > > >=20 > > > > > > 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 pra= ctice, and remove > > > > > > a few existing being experimental references in the doxygen com= ments. > > > > >=20 > > > > > I think, accidentally we can not make a library as NON-experiment= al. > > > > > TM never went through experimental to mature transition(see git l= og > > > > > 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 impleme= nted > > > > > by one or two HW. > > > >=20 > > > > Fair enough, specially if the API is not ready yet. > > > >=20 > > > > But they were part of stable ABI, and marking them as experimental = now will > > > > break the old applications using these APIs. > > >=20 > > > it is still marked as EXPERIMENTAL everywhere and API is not ready ye= t. > >=20 > > Existing experimental marks are text only for human parsing. > >=20 > > The compiler attribute and build time checks are missing, and the symbo= l in the > > binary doesn't have experimental tag. Our scripts and automated checks = won't > > detect it as experimental. > >=20 > > My point is just having experimental comment in header file is not enou= gh to > > qualify the APIs as experimental. > >=20 > > > Anyway, we need to break the ABI to make it work on various HW. > > > I am not sure what to do? > > > IMO, We need to send a patch as Fixes: for the bug of not adding > > > __rte_experimental in each function. > >=20 > > Yes, this is where we are, both you and Cristian suggest API is not rea= dy and > > should be experimental, but they were part of stable ABI, making them > > experimental will break the ABI. > > It looks like there is no good option but we should select one of the b= ad ones. > >=20 > > > Traffic Management API - EXPERIMENTAL > > > M: Cristian Dumitrescu > > > T: git://dpdk.org/next/dpdk-next-qos > > > F: lib/librte_ethdev/rte_tm* > > > > > > Ray, Neil, David, Luca, Kevin, what do you think? > While I'm not called any of those names, allow me to give my 2c. >=20 > Since these are marked in binaries as part of the stable ABI, I think we > need to honour that for the next two releases 20.05 and 20.08 [which mean= s > that we need to put in versioned functions for any changes, not that we > can't change anything] >=20 > For 20.11, I think these should then have one of two options taken: > * have these "fixed" and ready to be marked as stable, and officially par= t > of v21 ABI or > * mark them as experimental properly, and look to have them as part of th= e > v22 or subsequent ABI >=20 > Given the comments here, I would tend towards the latter of the above two > options, but that's really a decision for the maintainers. >=20 > Remember, this is not the first bug we have encountered where we messed u= p > some ABI versions in the 19.11 release, and, like the previous one with t= he > screwed up version number, I think we need to honour the ABI committments > made, especially since in this case it's only for a few more months till > 20.11 development starts. >=20 > /Bruce +1 If they are not ready now, they haven't been ready for the past 6 months either, so staying not ready for 6 more is the lesser evil. --=20 Kind regards, Luca Boccassi