On Mon, Dec 18, 2017 at 01:51:52PM +0000, Wiles, Keith wrote: > > > > On Dec 15, 2017, at 4:41 AM, Hemant Agrawal <hemant.agra...@nxp.com> wrote: > > > > Introduce a new argument ops_name in rte_mempool_set_ops_byname > > for allowing the application to optionally specify the mempool ops. > > > > Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com> > > --- > > v2: fix checkpatch error > > > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 13e8543..968ca14 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -53,3 +53,6 @@ Deprecation Notices > > > > * librte_meter: The API will change to accommodate configuration profiles. > > Most of the API functions will have an additional opaque parameter. > > + > > +* librte_mbuf: a new optional parameter for representing name of > > mempool_ops > > + will be added to the API ``rte_pktmbuf_pool_create``. > > > Sorry, for the late response I was on vacation. > > My question is why do we need to change rte_pktmbuf_pool_create ABI yet > again, why could we not add a new API to just set the name of the pool after > it is created. This would allow all current applications to work without any > ABI breakage and only require adding a new API call for anyone that wants the > name. The rte_pktmbuf_pool_create() routine could assign a default name or > some incrementing style name as the default. e.g. ‘pktmbuf_%d’ with a static > incrementing variable or whatever you like. > > Sorry if this was asked and answered before. +1, that seems like the more flexible solution. Neil
> > > -- > > 2.7.4 > > > > Regards, > Keith >
