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.
Thanks,
David.
