[dpdk-dev] [pull-request] next-tm 17.08 pre-rc1

Dumitrescu, Cristian cristian.dumitrescu at intel.com
Mon Jul 10 17:46:19 CEST 2017



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Monday, July 10, 2017 2:50 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>
> Cc: dev at dpdk.org; jerin.jacob at caviumnetworks.com;
> hemant.agrawal at nxp.com; Singh, Jasvinder <jasvinder.singh at intel.com>;
> Lu, Wenzhuo <wenzhuo.lu at intel.com>; O'Driscoll, Tim
> <tim.odriscoll at intel.com>; Glynn, Michael J <michael.j.glynn at intel.com>;
> Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> Subject: Re: [dpdk-dev] [pull-request] next-tm 17.08 pre-rc1
> 
> 10/07/2017 15:21, Dumitrescu, Cristian:
> > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > > 10/07/2017 12:55, Dumitrescu, Cristian:
> > > > From: Thomas Monjalon [mailto:thomas at 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?

Why do you think it is useless? How would the driver get the function specific (i.e. rte_flow, rte_tm, ...) operations structure?

I am afraid of reopening a lengthy discussion that we had when the time was right ...



More information about the dev mailing list