[dpdk-dev] new QoS/TM API and tree

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Tuesday, March 28, 2017 11:21 AM
> To: Thomas Monjalon <thomas.monjalon at 6wind.com>
> Cc: techboard at dpdk.org; Dumitrescu, Cristian
> <cristian.dumitrescu at intel.com>; dev at dpdk.org;
> hemant.agrawal at nxp.com
> Subject: Re: new QoS/TM API and tree
> 
> On Tue, Mar 28, 2017 at 12:15:39PM +0200, Thomas Monjalon wrote:
> > 2017-03-28 10:09, Dumitrescu, Cristian:
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > 2017-03-28 09:41, Dumitrescu, Cristian:
> > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > > > The last detail to discuss is the name of this tree.
> > > > > > As it is probably going to be an important amount of work, this tree
> > > > > > can live indefinitely as a next- tree to be pulled before each RC1.
> > > > > > The suggested names were dpdk-next-qos and dpdk-next-tm.
> > > > > >
> > > > > > The question is equivalent to choose a name for the new API.
> > > > > > Should it be rte_qos or rte_tm?
> > > > >
> > > > > Quality of Service (QoS) is a very generous concept that includes the
> egress
> > > > Traffic Management features such as hierarchical scheduling, traffic
> shaping,
> > > > congestion management, etc.; the QoS concept also includes the
> ingress
> > > > Traffic Metering and Policing.
> > > > >
> > > > > Therefore, I think the sensible approach is:
> > > > > 	API name (already debated on V2 thread: rte_scheddev, rte_tm,
> > > > rte_tman, etc): rte_tm
> > > > > 	Repository name: dpdk-next-qos or dpdk-next-tm (your choice)
> > > > >
> > > > > > Please let's think how it can evolve in future versions.
> > > >
> > > > The question is:
> > > > Are we sure that every features included in this "next" repo will be
> > > > only about Traffic Management?
> > >
> > > What we are 100% sure of is the API name of rte_tm, as this API is
> exclusively targeting traffic management.
> > >
> > > I agree with you that dpdk-next-qos would be a better name for the repo
> (instead of dpdk-next-tm), in case we want to add other QoS functionality to
> ethdev over time, such as traffic metering and policing. Of course, this is
> subject to community interest and Tech Board approval.
> > >
> > > > Detailed in two questions:
> > > > - Are we sure the QoS API of ethdev will be only about Traffic
> Management?
> > > > - Do we want to manage other QoS code areas in this "next" repo?
> >
> > I think it should be dpdk-next-qos and manage also the existing QoS libs.
> > Can we have an agreement by most of the techboard members please?
> 
> IMO, If we are moving all QoS related libraries(lib/librte_meter,
> lib/librte_sched and proposed tm library) to next tree then probably 'next-
> qos'
> make sense. If the scope is limited only for proposed tm library then
> next-tm make sense.
> 

Agree. Let's call the repo dpdk-next-tm and let's limit the scope to TM API, according to the mandate approved by the Tech Board.

Thomas, can we please create this tree asap without any further delay? We need to start the driver development and we are currently blocked by the repo not being created yet. Thanks!