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

Thomas Monjalon thomas at monjalon.net
Mon Jul 10 15:49:37 CEST 2017


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?


More information about the dev mailing list