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

[Thomas Monjalon <thomas@monjalon.net>]

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