[dpdk-dev] [PATCH 2/6] mempool: add stack (lifo) based external mempool handler

Olivier MATZ olivier.matz at 6wind.com
Fri Mar 4 10:04:57 CET 2016


Hi David,

On 02/29/2016 12:04 PM, Hunt, David wrote:
> 
> On 2/19/2016 1:31 PM, Olivier MATZ wrote:
>> Hi David,
>>
>> On 02/16/2016 03:48 PM, David Hunt wrote:
>>> adds a simple stack based mempool handler
>>>
>>> Signed-off-by: David Hunt <david.hunt at intel.com>
>>> ---
>>>   lib/librte_mempool/Makefile            |   2 +-
>>>   lib/librte_mempool/rte_mempool.c       |   4 +-
>>>   lib/librte_mempool/rte_mempool.h       |   1 +
>>>   lib/librte_mempool/rte_mempool_stack.c | 164
>>> +++++++++++++++++++++++++++++++++
>>>   4 files changed, 169 insertions(+), 2 deletions(-)
>>>   create mode 100644 lib/librte_mempool/rte_mempool_stack.c
>>>
>> I don't get what is the purpose of this handler. Is it an example
>> or is it something that could be useful for dpdk applications?
>>
>> If it's an example, we should find a way to put the code outside
>> the librte_mempool library, maybe in the test program. I see there
>> is also a "custom handler". Do we really need to have both?
> They are both example handlers. I agree that we could reduce down to
> one, and since the 'custom' handler has autotests, I would suggest we
> keep that one.

ok

> The next question is where it should live. I agree that it's not ideal
> to have example code living in the same directory as the mempool
> library, but they are an integral part of the library itself. How about
> creating a handlers sub-directory? We could then keep all additional and
> sample handlers in there, away from the built-in handlers. Also, seeing
> as the handler code is intended to be part of the library, I think
> moving it out to the examples directory may confuse matters further.

I really don't think example code should go in the library. Either it
should go in dpdk/examples/ or in dpdk/app/test*.

>From your initial description: "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."

Can we find a hardware where the external mempool manager is required?
This would be the best example ever I think.

Regards,
Olivier


More information about the dev mailing list