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

[Nithin Dabilpuram]

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.