From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: new QoS/TM API and tree
Date: Tue, 28 Mar 2017 11:56:53 +0200
Message-ID: <1783560.U3ricBZEab@xps13>
References: <2544195.RoHNEuVALo@xps13>
 <3EB4FA525960D640B5BDFFD6A3D891265277FF26@IRSMSX108.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
 "jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
 [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 33AD336E
 for <dev@dpdk.org>; Tue, 28 Mar 2017 11:56:56 +0200 (CEST)
Received: by mail-wr0-f170.google.com with SMTP id w43so82558762wrb.0
 for <dev@dpdk.org>; Tue, 28 Mar 2017 02:56:56 -0700 (PDT)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265277FF26@IRSMSX108.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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?