On Fri, Jan 29, 2016 at 01:40:40PM +0000, Hunt, David wrote:

On 28/01/2016 17:26, Jerin Jacob wrote:

quoted

On Tue, Jan 26, 2016 at 05:25:50PM +0000, David Hunt wrote:

quoted

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.

quoted

quoted

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.