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 <d...@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.
