[dpdk-dev] [PATCH 1/2] drivers/mempool: add stack mempool handler as driver

Shreyansh Jain shreyansh.jain at nxp.com
Tue Mar 21 07:28:52 CET 2017


On Tuesday 21 March 2017 11:55 AM, Shreyansh Jain wrote:
> Hello Keith,
>
> On Tuesday 21 March 2017 11:32 AM, Wiles, Keith wrote:
>>
>>> On Mar 20, 2017, at 11:55 PM, Shreyansh Jain <shreyansh.jain at nxp.com>
>>> wrote:
>>>
>>> Hello David,
>>>
>>> On Monday 20 March 2017 08:20 PM, Hunt, David wrote:
>>>>
>>>> On 20/3/2017 10:03 AM, Shreyansh Jain wrote:
>>>>> CONFIG_RTE_DRIVER_MEMPOOL_STACK option added to common_base.
>>>>> Stack mempool handler moved from lib/librte_mempool into
>>>>> drivers/mempool.
>>>>>
>>>
>>> <...>
>>>
>>>>> -}
>>>>> -
>>>>> -static struct rte_mempool_ops ops_stack = {
>>>>> -    .name = "stack",
>>>>> -    .alloc = stack_alloc,
>>>>> -    .free = stack_free,
>>>>> -    .enqueue = stack_enqueue,
>>>>> -    .dequeue = stack_dequeue,
>>>>> -    .get_count = stack_get_count
>>>>> -};
>>>>> -
>>>>> -MEMPOOL_REGISTER_OPS(ops_stack);
>>>>
>>>> Shreyansh,
>>>>    Could I suggest you add the parameter "--find-renames" when
>>>> generating the patch files, as this will reduce the size of the patches
>>>> significantly, making for easier review. The patch line count in this
>>>> particular case would be reduced by approx 75%.
>>>
>>> Thanks for suggestion.
>>> Yes, I forgot to use this option while creating this patch. If there
>>> are comments and v2 needs to be created, I will keep this in mind.
>>>
>>>> Regards,
>>>> Dave.
>>
>> I guess I missed an email, but what is the advantage of moving the
>> ring/stack files to the drivers directory as they are not drivers in
>> the sense of a NIC PMD or any other driver. You can still
>> enable/disable them in the config files right?
>>
>
> Just as reference, following is where this was being discussed:
>
> http://dpdk.org/ml/archives/dev/2017-March/059690.html
> http://dpdk.org/ml/archives/dev/2017-March/059753.html
> and
> http://dpdk.org/ml/archives/dev/2017-March/060501.html
>
> Also, a while back (I can't trace that mailing list exchange), it was
> decided that all mempool drivers (stack, ring, others...) would be
> moved to drivers/mempool.

Just to add, discussion at that time was to have:

drivers/bus/<buses using rte_bus>
drivers/mempool/<Offloaded, or not-offloaded memory pool handlers>
drivers/net/<usual PMDs>

There was a drivers/common as well, but somehow it didn't go down well 
in discussions.

>
> For NXP's DPAA2 PMD, we use an offloaded mempool for which there was a
> patchset by Hemant [1] which adds that driver to drivers/mempool. In
> the same breadth, ring and stack are also being moved to
> drivers/mempool as independent drivers (non-offloaded category).
>
> [1] http://dpdk.org/ml/archives/dev/2017-March/060476.html
>
> In my opinion, this would make the lib/* area free of handler/drivers
> (almost) and it is a good change. Also, ring and stack use a
> 'registration' mechanism - just like PMD and are good candidate to be
> treated as 'drivers' now even though not entirely like a PMD.
>
> You see any downside of this?
>
>> Regards,
>> Keith
>>
>>
>
> -
> Shreyansh
>
>



More information about the dev mailing list