From: Don Wallwork <donw@xsightlabs.com>
To: Thomas Monjalon <thomas@monjalon.net>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, "Stephen Hemminger" <stephen@networkplumber.org>,
"Chengwen Feng" <fengchengwen@huawei.com>,
"Morten Brørup" <mb@smartsharesystems.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
"Honnappa Nagarahalli" <Honnappa.Nagarahalli@arm.com>,
nd <nd@arm.com>, "Wang, Haiyue" <haiyue.wang@intel.com>,
Kathleen.Capella@arm.com
Subject: Re: [PATCH v6] eal: allow worker lcore stacks to be allocated from hugepage memory
Date: Tue, 21 Jun 2022 10:52:43 -0400 [thread overview]
Message-ID: <c4ddba4c-41c4-9204-4893-4097afb300cd@xsightlabs.com> (raw)
In-Reply-To: <6401977.6fTUFtlzNn@thomas>
On 6/21/2022 10:42 AM, Thomas Monjalon wrote:
> 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.
The command could be rejected if hugepages are not available.
That's not in the patch currently, but can be added.
next prev parent reply other threads:[~2022-06-21 14:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 14:10 [PATCH] " Don Wallwork
2022-05-03 6:10 ` Morten Brørup
2022-05-03 13:08 ` Wang, Haiyue
2022-05-03 19:46 ` Don Wallwork
2022-05-04 3:08 ` Wang, Haiyue
2022-05-13 17:58 ` [PATCH v2] " Don Wallwork
2022-05-13 21:38 ` Stephen Hemminger
2022-05-16 19:43 ` Don Wallwork
2022-05-13 21:41 ` Stephen Hemminger
2022-05-14 3:31 ` fengchengwen
2022-05-16 19:47 ` Don Wallwork
2022-05-17 6:28 ` Morten Brørup
2022-05-16 19:50 ` [PATCH v3] " Don Wallwork
2022-05-16 20:28 ` Stephen Hemminger
2022-05-16 20:29 ` Don Wallwork
2022-05-17 15:31 ` [PATCH v4] " Don Wallwork
2022-05-17 15:56 ` Stephen Hemminger
2022-05-18 14:10 ` Don Wallwork
2022-05-20 8:30 ` fengchengwen
2022-05-23 22:35 ` Kathleen Capella
2022-05-24 13:48 ` Don Wallwork
2022-05-24 14:40 ` Burakov, Anatoly
2022-05-24 19:38 ` Don Wallwork
2022-05-24 19:46 ` [PATCH v5] " Don Wallwork
2022-05-24 19:51 ` [PATCH v6] " Don Wallwork
2022-06-01 0:05 ` Kathleen Capella
2022-06-20 8:35 ` David Marchand
2022-06-21 10:37 ` Thomas Monjalon
2022-06-21 12:31 ` Don Wallwork
2022-06-21 14:42 ` Thomas Monjalon
2022-06-21 14:52 ` Don Wallwork [this message]
2022-06-21 15:00 ` Thomas Monjalon
2022-06-21 16:32 ` Honnappa Nagarahalli
2022-06-21 19:33 ` David Marchand
2022-06-23 11:21 ` [PATCH v7] " Don Wallwork
2022-06-23 20:32 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4ddba4c-41c4-9204-4893-4097afb300cd@xsightlabs.com \
--to=donw@xsightlabs.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Kathleen.Capella@arm.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=fengchengwen@huawei.com \
--cc=haiyue.wang@intel.com \
--cc=mb@smartsharesystems.com \
--cc=nd@arm.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).