2016-06-17 09:42, Hunt, David:
> 
> On 17/6/2016 9:08 AM, Olivier Matz wrote:
> > Hi David,
> >
> > On 06/17/2016 08:58 AM, Hunt, David wrote:
> >> A comment below:
> >>
> >> On 16/6/2016 1:30 PM, David Hunt wrote:
> >>> +/**
> >>> + * Set the ops of a mempool.
> >>> + *
> >>> + * This can only be done on a mempool that is not populated, i.e.
> >>> just after
> >>> + * a call to rte_mempool_create_empty().
> >>> + *
> >>> + * @param mp
> >>> + *   Pointer to the memory pool.
> >>> + * @param name
> >>> + *   Name of the ops structure to use for this mempool.
> >> + * @param pool_config
> >> + *   Opaque data that can be used by the ops functions.
> >>> + * @return
> >>> + *   - 0: Success; the mempool is now using the requested ops functions.
> >>> + *   - -EINVAL - Invalid ops struct name provided.
> >>> + *   - -EEXIST - mempool already has an ops struct assigned.
> >>> + */
> >>> +int
> >>> +rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
> >>> +        void *pool_config);
> >>> +
> >>
> > The changes related to the pool_config look good to me.
> >
> > If you plan to do a v14 for this API comment, I'm wondering if the
> > documentation could be slightly modified too. I think "external mempool
> > manager" was the legacy name for the feature, but maybe it could be
> > changed in "alternative mempool handlers" or "changing the mempool
> > handler". I mean the word "external" is probably not appropriate now,
> > especially if we add other handlers in the mempool lib.
> >
> > My 2 cents,
> > Olivier
> 
> I had not planned on doing another revision. And I think the term "External
> Mempool Manager" accurately describes the functionality, so I'd really
> prefer to leave it as it is.

I think there is no manager, just a default handler which can be changed.
I agree the documentation must be fixed.

Reply via email to