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

[Nithin Dabilpuram]

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.