From: Nissim Nisimov <NissimN@Radware.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "'dev@dpdk.org'" <dev@dpdk.org>
Subject: Re: [dpdk-dev] propose a solution for mapping same virtual address space to asymmetric processes
Date: Tue, 13 Oct 2015 17:26:09 +0000 [thread overview]
Message-ID: <cb9aef7c-32e8-406b-9996-87c6ff60f59d@radware.com> (raw)
In-Reply-To: <59AF69C657FD0841A61C55336867B5B03595A760@IRSMSX103.ger.corp.intel.com>
Hi Bruce,
Using "--base-virtaddr" requires knowledge on the huge pages wanted address going to be used and might vary on different uses of the application.
We suggest a more generic solution which wont require any previous knowledge and will be "bullet proof" as much as possible.
Regards,
Nissim
On Oct 13, 2015 18:49, "Richardson, Bruce" <bruce.richardson@intel.com> wrote:
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Nissim Nisimov
> Sent: Tuesday, October 13, 2015 4:40 PM
> To: 'dev@dpdk.org'
> Subject: [dpdk-dev] propose a solution for mapping same virtual address
> space to asymmetric processes
>
> Hi all,
>
> The below will try to suggest a modification to the initialization of
> Environment Abstraction Layer (AKA EAL) so it will be able to allocate
> memory zones from same virtual memory addresses even if the primary
> process is not similar to the secondary processes.
>
> Problem:
> The DPDK Primary/Secondary model requires that the exact same hugepage
> memory mappings be present in all applications.
> An issue may occur when the Primary and secondary processes are not
> symmetric in such way that the code has big differences (for example,
> Primary process is a traffic distributer and secondary is a worker).
> The result may be that specific virtual address region in the first
> process won't be available in the second process.
>
>
> Suggested solution:
> Map all related rte and uio sections somewhere close to the end of huge
> pages memory (that mean rte_eal_memory_init() should be called before
> rte_config_init() in primary process) According to our observations there
> will be more probability to success when allocating the above sections
> after huge pages section (actually uio is already allocated after the huge
> pages area)
>
> It solved our problem when trying to work with a primary traffic
> distributer which is a very "light" process and few secondary worker
> processes.
>
>
> Please share your thoughts on this before I will try to commit our patch
> for review
>
> Thanks,
> Nissim
Hi,
out of interest, have you tried fixing the issue using the "--base-virtaddr" EAL flag to hint a base address to the primary process? It was put into the code some time ago to help solve exactly this problem.
/Bruce
prev parent reply other threads:[~2015-10-13 17:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 15:40 Nissim Nisimov
2015-10-13 15:49 ` Richardson, Bruce
2015-10-13 17:26 ` Nissim Nisimov [this message]
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=cb9aef7c-32e8-406b-9996-87c6ff60f59d@radware.com \
--to=nissimn@radware.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/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).