[PATCH v6] eal: allow worker lcore stacks to be allocated from hugepage memory

Don Wallwork donw at xsightlabs.com
Tue Jun 21 14:31:39 CEST 2022


On 6/21/2022 6:37 AM, Thomas Monjalon wrote:
> 20/06/2022 10:35, David Marchand:
>> On Tue, May 24, 2022 at 9:52 PM Don Wallwork <donw at xsightlabs.com> wrote:
>>> Add support for using hugepages for worker lcore stack memory.  The
>>> intent is to improve performance by reducing stack memory related TLB
>>> misses and also by using memory local to the NUMA node of each lcore.
>>> EAL option '--huge-worker-stack [stack-size-in-kbytes]' is added to allow
>>> the feature to be enabled at runtime.  If the size is not specified,
>>> the system pthread stack size will be used.
>> - About the name of the option... I don't have a better name.
>>
>> Just want to highlight, that what this patch does is use the DPDK
>> memory allocator for the stack memory.
>> It happens that DPDK memory allocator is primarily used with
>> hugepages, but this is not systematic for example with the "no-huge"
>> mode of the DPDK memory allocator.
>>
>> IOW, in this patch current form, you can still run as:
>>
>> # dpdk-testpmd -c 3 --no-huge --huge-worker-stack=16 -m 40 -- etc...
>>
>> Opinions?
> The name of the option should not include "huge".
> What about "--worker-stack" ?
> If disabled (equal zero), the workers should use the default stack memory.
>
>
Wouldn't that have the potential to create confusion?  The point of this
change is to allocate worker stacks from hugepages.  Removing huge
from the option name could give the impression that the command is
simply to control worker stack size.

Regarding your other comments, I'm working on another patch that will
address those.


More information about the dev mailing list