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 2CA62A00BE; Tue, 28 Apr 2020 17:42:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 765A01D60A; Tue, 28 Apr 2020 17:42:32 +0200 (CEST) Received: from qrelay37.mxroute.com (qrelay37.mxroute.com [172.82.139.37]) by dpdk.org (Postfix) with ESMTP id 7A0981D609 for ; Tue, 28 Apr 2020 17:42:30 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay37.mxroute.com (ZoneMTA) with ESMTPA id 171c17421aa0000d83.002 for ; Tue, 28 Apr 2020 15:42:25 +0000 X-Zone-Loop: a14c29458b6e382871ab64cf7314c5bb35f1e9f7e77b X-Originating-IP: [149.28.56.236] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter004.mxroute.com (Postfix) with ESMTPS id 2C76F3E9E7; Tue, 28 Apr 2020 15:42:20 +0000 (UTC) Received: from [192.198.151.44] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1jTRx9-0000dn-Nf; Tue, 28 Apr 2020 11:15:20 -0400 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 , Luca Boccassi , Kevin Traynor , David Marchand 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> From: Ray Kinsella Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: Date: Tue, 28 Apr 2020 16:42:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200428144535.GC1897@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu 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 28/04/2020 15:45, 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: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Yigit, Ferruh >>>>>>>> Sent: Saturday, April 25, 2020 9:09 PM >>>>>>>> To: Dumitrescu, Cristian ; Nithin Dabilpuram >>>>>>>> ; Singh, Jasvinder ; >>>>>>>> Thomas Monjalon ; Andrew Rybchenko >>>>>>>> >>>>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; kkanas@marvell.com; Nithin >>>>>>>> Dabilpuram >>>>>>>> Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt >>>>>>>> mode >>>>>>>> >>>>>>>> On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Nithin Dabilpuram >>>>>>>>>> Sent: Wednesday, April 22, 2020 6:21 PM >>>>>>>>>> To: Singh, Jasvinder ; Dumitrescu, Cristian >>>>>>>>>> ; Thomas Monjalon >>>>>>>>>> ; Yigit, Ferruh ; Andrew >>>>>>>>>> Rybchenko >>>>>>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; kkanas@marvell.com; Nithin >>>>>>>>>> Dabilpuram >>>>>>>>>> Subject: [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt >>>>>>>>>> mode >>>>>>>>>> >>>>>>>>>> From: Nithin Dabilpuram >>>>>>>>>> >>>>>>>>>> Some NIC hardware support shaper to work in packet mode i.e >>>>>>>>>> shaping or ratelimiting traffic is in packets per second (PPS) as >>>>>>>>>> opposed to default bytes per second (BPS). Hence this patch >>>>>>>>>> adds support to configure shared or private shaper in packet mode, >>>>>>>>>> provide rate in PPS and add related tm capabilities in port/level/node >>>>>>>>>> capability structures. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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 comments. >>>>>>>>>> - Add error enum >>>>>>>> RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE >>>>>>>>>> - Fix shaper_profile_check() with packet mode check >>>>>>>>>> - Fix typo's >>>>>>>>>> >>>>>>>>> >>>>>>>>> Acked-by: Cristian Dumitrescu >>>>>>>>> >>>>>>>> >>>>>>>> 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. >>>> >>>> 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. >> >> 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. >>> 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. >> >> Yes, this is where we are, both you and Cristian suggest API is not ready 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 bad ones. >> >>> >>> 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. > > 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 means > that we need to put in versioned functions for any changes, not that we > can't change anything] > > 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 part > of v21 ABI or > * mark them as experimental properly, and look to have them as part of the > v22 or subsequent ABI > > Given the comments here, I would tend towards the latter of the above two > options, but that's really a decision for the maintainers. > > Remember, this is not the first bug we have encountered where we messed up > some ABI versions in the 19.11 release, and, like the previous one with the > 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. > > /Bruce > So the rte_tm API has been "EXPERIMENTAL" for quiet a long time, as far back as v17.11. To the extent it predates the experimental infrastructure the community developed since then. TM added in 17.08, EXPERIMENTAL appears to have been added in 17.11. That said, some form of stable TM API should have emerged by this point. So I am not sure that EXPERIMENTAL status was 100% warranted. As Bruce points out. It is simpler to wait for the next ABI breakage window in August. And mark them EXPERIMENTAL at that point. Thanks, Ray K