* [dpdk-dev] new QoS/TM API and tree
@ 2017-03-28 8:44 Thomas Monjalon
2017-03-28 9:41 ` Dumitrescu, Cristian
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2017-03-28 8:44 UTC (permalink / raw)
To: dev; +Cc: cristian.dumitrescu, hemant.agrawal, jerin.jacob
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 8:44 [dpdk-dev] new QoS/TM API and tree Thomas Monjalon
@ 2017-03-28 9:41 ` Dumitrescu, Cristian
2017-03-28 9:56 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Dumitrescu, Cristian @ 2017-03-28 9:41 UTC (permalink / raw)
To: Thomas Monjalon, dev; +Cc: hemant.agrawal, jerin.jacob
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 9:41 ` Dumitrescu, Cristian
@ 2017-03-28 9:56 ` Thomas Monjalon
2017-03-28 10:09 ` Dumitrescu, Cristian
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2017-03-28 9:56 UTC (permalink / raw)
To: Dumitrescu, Cristian; +Cc: dev, hemant.agrawal, jerin.jacob
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 9:56 ` Thomas Monjalon
@ 2017-03-28 10:09 ` Dumitrescu, Cristian
2017-03-28 10:15 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Dumitrescu, Cristian @ 2017-03-28 10:09 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, hemant.agrawal, jerin.jacob
> -----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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 10:09 ` Dumitrescu, Cristian
@ 2017-03-28 10:15 ` Thomas Monjalon
2017-03-28 10:20 ` Jerin Jacob
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2017-03-28 10:15 UTC (permalink / raw)
To: techboard; +Cc: Dumitrescu, Cristian, dev, hemant.agrawal, jerin.jacob
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 10:15 ` Thomas Monjalon
@ 2017-03-28 10:20 ` Jerin Jacob
2017-03-28 10:24 ` Dumitrescu, Cristian
0 siblings, 1 reply; 8+ messages in thread
From: Jerin Jacob @ 2017-03-28 10:20 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: techboard, Dumitrescu, Cristian, dev, hemant.agrawal
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.
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 10:20 ` Jerin Jacob
@ 2017-03-28 10:24 ` Dumitrescu, Cristian
2017-03-28 12:47 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Dumitrescu, Cristian @ 2017-03-28 10:24 UTC (permalink / raw)
To: Jerin Jacob, Thomas Monjalon; +Cc: techboard, dev, hemant.agrawal
> -----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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] new QoS/TM API and tree
2017-03-28 10:24 ` Dumitrescu, Cristian
@ 2017-03-28 12:47 ` Thomas Monjalon
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Monjalon @ 2017-03-28 12:47 UTC (permalink / raw)
To: Dumitrescu, Cristian; +Cc: Jerin Jacob, techboard, dev, hemant.agrawal
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-03-28 12:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-28 8:44 [dpdk-dev] new QoS/TM API and tree Thomas Monjalon
2017-03-28 9:41 ` Dumitrescu, Cristian
2017-03-28 9:56 ` Thomas Monjalon
2017-03-28 10:09 ` Dumitrescu, Cristian
2017-03-28 10:15 ` Thomas Monjalon
2017-03-28 10:20 ` Jerin Jacob
2017-03-28 10:24 ` Dumitrescu, Cristian
2017-03-28 12:47 ` Thomas Monjalon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).