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

Thomas Monjalon thomas.monjalon at 6wind.com
Tue Mar 28 12:15:39 CEST 2017


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?



More information about the dev mailing list