21/06/2022 14:31, Don Wallwork: > 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.
It means if we control the worker stack size with a DPDK option, DPDK memory will be used. But we cannot force hugepage with this option. Hugepage is not always available and it can be disabled in DPDK. > Regarding your other comments, I'm working on another patch that will > address those.
