On Fri, Jan 29, 2016 at 01:40:40PM +0000, Hunt, David wrote:
> On 28/01/2016 17:26, Jerin Jacob wrote:
> >On Tue, Jan 26, 2016 at 05:25:50PM +0000, David Hunt wrote:
> >>Hi all on the list.
> >>
> >>Here's a proposed patch for an external mempool manager
> >>
> >>The External Mempool Manager is an extension to the mempool API that allows
> >>users to add and use an external mempool manager, which allows external
> >>memory
> >>subsystems such as external hardware memory management systems and software
> >>based memory allocators to be used with DPDK.
> >
> >I like this approach.It will be useful for external hardware memory
> >pool managers.
> >
> >BTW, Do you encounter any performance impact on changing to function
> >pointer based approach?
>
> Jerin,
> Thanks for your comments.
>
> The performance impacts I've seen depends on whether I'm using an object
> cache for the mempool or not. Without object cache, I see between 0-10%
> degradation. With object cache, I see a slight performance gain of between
> 0-5%. But that will most likely vary from system to system.
>
> >>The existing API to the internal DPDK mempool manager will remain unchanged
> >>and will be backward compatible.
> >>
> >>There are two aspects to external mempool manager.
> >> 1. Adding the code for your new mempool handler. This is achieved by
> >> adding a
> >> new mempool handler source file into the librte_mempool library, and
> >> using the REGISTER_MEMPOOL_HANDLER macro.
> >> 2. Using the new API to call rte_mempool_create_ext to create a new
> >> mempool
> >> using the name parameter to identify which handler to use.
> >>
> >>New API calls added
> >> 1. A new mempool 'create' function which accepts mempool handler name.
> >> 2. A new mempool 'rte_get_mempool_handler' function which accepts mempool
> >> handler name, and returns the index to the relevant set of callbacks
> >> for
> >> that mempool handler
> >>
> >>Several external mempool managers may be used in the same application. A new
> >>mempool can then be created by using the new 'create' function, providing
> >>the
> >>mempool handler name to point the mempool to the relevant mempool manager
> >>callback structure.
> >>
> >>The old 'create' function can still be called by legacy programs, and will
> >>internally work out the mempool handle based on the flags provided (single
> >>producer, single consumer, etc). By default handles are created internally
> >>to
> >>implement the built-in DPDK mempool manager and mempool types.
> >>
> >>The external mempool manager needs to provide the following functions.
> >> 1. alloc - allocates the mempool memory, and adds each object onto a
> >> ring
> >> 2. put - puts an object back into the mempool once an application
> >> has
> >> finished with it
> >> 3. get - gets an object from the mempool for use by the application
> >> 4. get_count - gets the number of available objects in the mempool
> >> 5. free - frees the mempool memory
> >>
> >>Every time a get/put/get_count is called from the application/PMD, the
> >>callback for that mempool is called. These functions are in the fastpath,
> >>and any unoptimised handlers may limit performance.
> >>
> >>The new APIs are as follows:
> >>
> >>1. rte_mempool_create_ext
> >>
> >>struct rte_mempool *
> >>rte_mempool_create_ext(const char * name, unsigned n,
> >> unsigned cache_size, unsigned private_data_size,
> >> int socket_id, unsigned flags,
> >> const char * handler_name);
> >>
> >>2. rte_get_mempool_handler
> >>
> >>int16_t
> >>rte_get_mempool_handler(const char *name);
> >
> >Do we need above public API as, in any case we need rte_mempool* pointer to
> >operate on mempools(which has the index anyway)?
> >
> >May a similar functional API with different name/return will be
> >better to figure out, given "name" registered or not in ethernet driver
> >which has dependency on a particular HW pool manager.
>
> Good point. An earlier revision required getting the index first, then
> passing that to the create_ext call. Now that the call is by name, the 'get'
> is mostly redundant. As you suggest, we may need an API for checking the
> existence of a particular manager/handler. Then again, we could always
> return an error from the create_ext api if it fails to find that handler.
> I'll remove the 'get' for the moment.
OK. But I think an API to get external pool manager name should be
required. It's useful in ethernet driver where driver needs to take care
of any special arrangement based on a specific any HW pool manager
something like below, feel free to chage the API name,
inline char* __attribute__((always_inline))
rte_mempool_ext_get_name(struct rte_mempool *mp)
{
return (mempool_handler_list.handler[mp->handler_idx].name)
}
>
> Thanks,
> David.
>
>
>
>
>
>
>
