From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, ray.kinsella@intel.com,
kuralamudhan.ramakrishnan@intel.com, louise.m.daly@intel.com,
bruce.richardson@intel.com, ferruh.yigit@intel.com,
konstantin.ananyev@intel.com
Subject: Re: [PATCH v2 7/9] eal: add --in-memory option
Date: Fri, 13 Jul 2018 13:27:56 +0100 [thread overview]
Message-ID: <793f3d26-306e-209e-f866-a13abf1a9042@intel.com> (raw)
In-Reply-To: <2408769.8CpHiMRGOD@xps>
On 13-Jul-18 1:13 PM, Thomas Monjalon wrote:
> 13/07/2018 12:27, Anatoly Burakov:
>> This command-line option will cause DPDK to operate entirely in
>> memory and not create any shared files at runtime, including any
>> shared configuration or hugetlbfs files. This is useful for debug
>> purposes, as well as for certain use cases like containers or
>> automatic memory cleanup.
>>
>> Currently, this option acts as a strict superset of --no-shconf and
>> --huge-unlink commands.
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>
> I would like to see some support or review for this feature.
>
While the justification for it can be use-cases like running a DPDK
process without worrying about cleaning up its hugepages afterwards
(somewhat less of a concern since 18.05 but still a concern if primary
crashes), it is really fixing the no-shconf/huge-unlink options to not
be half-measures.
Both of these options effectively disable secondary processes, but don't
do it in a consistent way - huge-unlink cleans up hugepages after
allocating them, but leaves shared config on. No-shconf disables shared
config, but leaves hugepages in place. Since 18.05, huge-unlink didn't
work anyway (wasn't implemented, which was my omission), and due to EAL
now relying on fbarray's to store some data, no-shconf wasn't working
correctly either because even though shared config wasn't created, two
primaries still couldn't share a prefix with --no-shconf (see the first
patch).
So, this patchset is really an acknowledgement of the fact that both
huge-unlink and no-shconf options are really there to disable secondary
processes and stop leaving files on the file system. I just went one
step further, and instead of allocating-and-then-removing hugepages
we're not creating them in the first place, and map them anonymously
instead.
--
Thanks,
Anatoly
next prev parent reply other threads:[~2018-07-13 12:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 17:15 [PATCH 0/9] Support running DPDK without hugetlbfs mountpoint Anatoly Burakov
2018-06-01 17:15 ` [PATCH 1/9] fbarray: support no-shconf mode Anatoly Burakov
2018-06-01 17:15 ` [PATCH 2/9] ipc: add support for " Anatoly Burakov
2018-06-01 17:15 ` [PATCH 3/9] eal: add support for no-shconf for hugepage info Anatoly Burakov
2018-06-01 17:15 ` [PATCH 4/9] eal: add support for no-shconf in hugepage data file Anatoly Burakov
2018-06-01 17:15 ` [PATCH 5/9] eal: do not create runtime dir in no-shconf mode Anatoly Burakov
2018-06-01 17:15 ` [PATCH 6/9] mem: add support for hugepage-unlink mode Anatoly Burakov
2018-06-01 17:15 ` [PATCH 7/9] eal: add --in-memory option Anatoly Burakov
2018-06-01 17:15 ` [PATCH 8/9] doc: add deprecation notice for EAL command line options Anatoly Burakov
2018-06-01 17:15 ` [PATCH 9/9] mem: support in-memory mode Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 0/9] Support running DPDK without hugetlbfs mountpoint Anatoly Burakov
2018-07-13 12:47 ` [PATCH v3 0/8] " Anatoly Burakov
2018-07-13 13:41 ` Thomas Monjalon
2018-07-13 12:47 ` [PATCH v3 1/8] fbarray: support no-shconf mode Anatoly Burakov
2018-07-13 12:47 ` [PATCH v3 2/8] ipc: add support for " Anatoly Burakov
2018-07-13 12:47 ` [PATCH v3 3/8] eal: add support for no-shconf for hugepage info Anatoly Burakov
2018-07-13 12:48 ` [PATCH v3 4/8] eal: add support for no-shconf in hugepage data file Anatoly Burakov
2018-07-13 12:48 ` [PATCH v3 5/8] eal: do not create runtime dir in no-shconf mode Anatoly Burakov
2018-07-13 12:48 ` [PATCH v3 6/8] mem: add support for hugepage-unlink mode Anatoly Burakov
2018-07-13 12:48 ` [PATCH v3 7/8] eal: add --in-memory option Anatoly Burakov
2018-07-13 12:48 ` [PATCH v3 8/8] mem: support in-memory mode Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 1/9] fbarray: support no-shconf mode Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 2/9] ipc: add support for " Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 3/9] eal: add support for no-shconf for hugepage info Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 4/9] eal: add support for no-shconf in hugepage data file Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 5/9] eal: do not create runtime dir in no-shconf mode Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 6/9] mem: add support for hugepage-unlink mode Anatoly Burakov
2018-07-13 10:27 ` [PATCH v2 7/9] eal: add --in-memory option Anatoly Burakov
2018-07-13 12:13 ` Thomas Monjalon
2018-07-13 12:27 ` Burakov, Anatoly [this message]
2018-07-13 10:27 ` [PATCH v2 8/9] doc: add deprecation notice for EAL command line options Anatoly Burakov
2018-07-13 12:13 ` Thomas Monjalon
2018-07-13 12:29 ` Burakov, Anatoly
2018-07-13 10:27 ` [PATCH v2 9/9] mem: support in-memory mode Anatoly Burakov
2018-07-13 12:15 ` Thomas Monjalon
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=793f3d26-306e-209e-f866-a13abf1a9042@intel.com \
--to=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=kuralamudhan.ramakrishnan@intel.com \
--cc=louise.m.daly@intel.com \
--cc=ray.kinsella@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.