From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [pull-request] next-tm 17.08 pre-rc1
Date: Mon, 10 Jul 2017 15:49:37 +0200
Message-ID: <1897417.adnAssk0iV@xps>
References: <1499182731-86830-1-git-send-email-cristian.dumitrescu@intel.com>
 <6030891.m1QB3o9leh@xps>
 <3EB4FA525960D640B5BDFFD6A3D891267BA7D90C@IRSMSX108.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org,
 "jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>, "Singh,
 Jasvinder" <jasvinder.singh@intel.com>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
 "O'Driscoll, Tim" <tim.odriscoll@intel.com>, "Glynn,
 Michael J" <michael.j.glynn@intel.com>,
 Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 4C29E5A6A
 for <dev@dpdk.org>; Mon, 10 Jul 2017 15:49:39 +0200 (CEST)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA7D90C@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>

10/07/2017 15:21, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 10/07/2017 12:55, Dumitrescu, Cristian:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 2/ Some functions are exposed in the API to query the ops.
> > > > It seems dangerous and useless:
> > > > 	- rte_eth_dev_tm_ops_get
> > > > 	- rte_tm_ops_get
> > >
> > > Thomas, hopefully this is a misunderstanding on your side :(((.
> > 
> > Don't worry :)
> > 
> > > This is a critical point that we debated ad nauseam on this email list (RFC, V1
> > -V6) and privately as well. You were included in the conversation, you also
> > provided feed-back that we incorporated in the code, as documented in the
> > patchset history log.
> > >
> > > This is simply the mechanism that we (including you) agreed to use for
> > modularizing the DPDK ethdev by adding new functionality in a modular plug-
> > in way using separate namespace. This is the exact clone of the same
> > mechanism that rte_flow is using and was merged in DPDK release 17.02.
> > Why this change on the fundamentals now?
> > >
> > > Hopefully, it is just misunderstanding.
> > 
> > I mean that only the drivers need to get the ops.
> > The applications are using some dedicated functions rte_tm_* , right?
> > So the applications does not need direct ops access with
> > rte_eth_dev_tm_ops_get()?
> > Sorry if it is my misunderstanding.
> > 
> > About rte_tm_ops_get, I don't remember why I talked about it.
> > It seems exposed only to drivers. My mistake. No issue there.
> 
> OK, so we're good then?

Not exactly. In my understanding, rte_eth_dev_tm_ops_get() is useless.
Should it be removed then?