[dpdk-dev] [EXT] Re: [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode

[Ferruh Yigit]

On 9/7/2020 12:12 PM, Nithin Dabilpuram wrote:
> On Tue, Aug 25, 2020 at 05:59:10PM +0100, Ferruh Yigit wrote:
>> On 5/1/2020 2:16 PM, Nithin Dabilpuram wrote:
>>> On Fri, May 01, 2020 at 11:27:02AM +0100, Ferruh Yigit wrote:
>>>> External Email
>>>>
>>>> ----------------------------------------------------------------------
>>>> On 4/29/2020 10:03 AM, Bruce Richardson wrote:
>>>>> On Wed, Apr 29, 2020 at 09:45:44AM +0100, Dumitrescu, Cristian wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Thomas Monjalon <thomas at monjalon.net>
>>>>>>> Sent: Tuesday, April 28, 2020 4:54 PM
>>>>>>> To: Jerin Jacob <jerinjacobk at gmail.com>; Dumitrescu, Cristian
>>>>>>> <cristian.dumitrescu at intel.com>
>>>>>>> Cc: Richardson, Bruce <bruce.richardson at intel.com>; Yigit, Ferruh
>>>>>>> <ferruh.yigit at intel.com>; Luca Boccassi <bluca at debian.org>; Nithin
>>>>>>> Dabilpuram <nithind1988 at gmail.com>; Singh, Jasvinder
>>>>>>> <jasvinder.singh at intel.com>; Andrew Rybchenko
>>>>>>> <arybchenko at solarflare.com>; dev at dpdk.org; jerinj at marvell.com;
>>>>>>> kkanas at marvell.com; Nithin Dabilpuram <ndabilpuram at marvell.com>;
>>>>>>> Kinsella, Ray <ray.kinsella at intel.com>; Neil Horman
>>>>>>> <nhorman at tuxdriver.com>; Kevin Traynor <ktraynor at redhat.com>; David
>>>>>>> Marchand <david.marchand at redhat.com>
>>>>>>> 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
>>>>>>> <ferruh.yigit at intel.com> wrote:
>>>>>>>>>>>> On 4/27/2020 5:29 PM, Jerin Jacob wrote:
>>>>>>>>>>>>> On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit
>>>>>>> <ferruh.yigit at intel.com> wrote:
>>>>>>>>>>>>>> On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote:
>>>>>>>>>>>>>>> From: Yigit, Ferruh <ferruh.yigit at intel.com>
>>>>>>>>>>>>>>>> On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote:
>>>>>>>>>>>>>>>>> From: Nithin Dabilpuram <nithind1988 at gmail.com>
>>>>>>>>>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_XYNFg14u&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=FZ_tPCbgFOh18zwRPO9H0yDx8VW38vuapifdDfc8SFQ&m=ej5sP3-cEhEoCTZOia-QivXqgljtzBcMLtZGs-5c-Uc&s=B8z_5mQ2xO3C1izjmRe2zBApMrCUcW6KcAN-adglhJQ&e= 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>
>>>>
>>>> Deferring the patchet for this release.
>>>>
>>>> Reminder that if the option "to mark rte_tm_* as experimental in v20.11"
>>>> selected, requires deprecation notice before v20.11.
>>>
>>> Thanks Ferruh for reminder. I'll send a deprecation notice patch for the same.
>>>
>>
>> Hi Nithin Kumar, Cristian, Jerin,
>>
>> Who is working on updating APIs as experimental? We need that patch to proceed
>> with this one.
> 
> Hi Ferruh,
> 
> I'll send out a patch marking all TM API's experimental.
> 

The experimental API change is done & applied,
hence for this series:

Series applied to dpdk-next-net/main, thanks.