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.monja...@6wind.com] > > > 2017-03-28 09:41, Dumitrescu, Cristian: > > > > From: Thomas Monjalon [mailto:thomas.monja...@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. >
