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

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

[Thomas Monjalon]

At the last techboard meeting, it has been accepted to create a new
git tree for the ongoing QoS work.
(see minutes http://dpdk.org/ml/archives/dev/2017-March/061009.html)

Quoting http://dpdk.org/ml/archives/dev/2017-March/060387.html
"
Can you please create a next-tree for QoS Traffic Management with the following details:
        Maintainer: Cristian
        Committers: Hemant, Jerin, Cristian
"

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?

Please let's think how it can evolve in future versions.

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

[Dumitrescu, Cristian]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, March 28, 2017 9:44 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> hemant.agrawal@nxp.com; jerin.jacob@caviumnetworks.com
> Subject: new QoS/TM API and tree
> 
> At the last techboard meeting, it has been accepted to create a new
> git tree for the ongoing QoS work.
> (see minutes http://dpdk.org/ml/archives/dev/2017-March/061009.html)
> 
> Quoting http://dpdk.org/ml/archives/dev/2017-March/060387.html
> "
> Can you please create a next-tree for QoS Traffic Management with the
> following details:
>         Maintainer: Cristian
>         Committers: Hemant, Jerin, Cristian
> "
> 
> 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.

Thanks,
Cristian

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

[Thomas Monjalon]

2017-03-28 09:41, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas.monjalon@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?

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?

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

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, March 28, 2017 10:57 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; hemant.agrawal@nxp.com;
> jerin.jacob@caviumnetworks.com
> Subject: Re: new QoS/TM API and tree
> 
> 2017-03-28 09:41, Dumitrescu, Cristian:
> > From: Thomas Monjalon [mailto:thomas.monjalon@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?

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

[Thomas Monjalon]

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

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

[Jerin Jacob]

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


> 

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

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Tuesday, March 28, 2017 11:21 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: techboard@dpdk.org; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> hemant.agrawal@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@6wind.com]
> > > > 2017-03-28 09:41, Dumitrescu, Cristian:
> > > > > From: Thomas Monjalon [mailto:thomas.monjalon@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!

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

[Thomas Monjalon]

2017-03-28 10:24, Dumitrescu, Cristian:
> 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!

The repository is created:
	http://dpdk.org/browse/next/dpdk-next-tm/

Private committer accesses are secured with SSH key.