From: Shahaf Shuler <shahafs@mellanox.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
"stable@dpdk.org" <stable@dpdk.org>,
"alejandro.lucero@netronome.com" <alejandro.lucero@netronome.com>
Subject: Re: [dpdk-dev] [PATCH] mem: don't use address hint for mapping unless requested
Date: Thu, 28 Mar 2019 08:45:39 +0000 [thread overview]
Message-ID: <AM0PR0502MB37950056006A83351B8FE929C3590@AM0PR0502MB3795.eurprd05.prod.outlook.com> (raw)
Message-ID: <20190328084539.d-FnqYtp0idrHeNdgfb8lEa2kLWGlOupEyzWXwlMOFM@z> (raw)
In-Reply-To: <0c3648af-015b-eddf-1967-becc670e42a2@intel.com>
Wednesday, March 27, 2019 1:50 PM, Burakov, Anatoly:
> Subject: Re: [PATCH] mem: don't use address hint for mapping unless
> requested
>
> On 21-Mar-19 8:21 PM, Shahaf Shuler wrote:
> > patch[1] added an address hint as starting address for 64 bit systems
> > in case an explicit base virtual address was not set by the user.
> >
> > The justification for such hint was to help devices that work in VA
> > mode and has a address range limitation to work smoothly with the eal
> > memory subsystem.
> >
> > While the base address value selected may work fine for the eal
> > initialization, it easily breaks when trying to register external
> > memory using rte_extmem_register API.
> >
> > Trying to register anonymous memory on RH x86_64 machine took several
> > minutes, during them the function eal_get_virtual_area repeatedly
> > scanned for a good VA candidate.
> >
> > The attempt to guess which VA address will be free for mapping will
> > always result in not portable, error prone code:
> > * different application may use different libraries along w/ DPDK. One
> > can never guess which library was called first and how much virtual
> > memory it consumed.
> > * external memory can be registered at any time in the application run
> > time.
> >
> > This patch removes the default address hint and use the address
> > returned by mmap.
> > devices with address limitations should suggest to their users a
> > proper base-virtaddr (EAL arg) to use.
> >
> > Fixes: 1df21702873d ("mem: use address hint for mapping hugepages")
> > Cc: stable@dpdk.org
> > Cc: alejandro.lucero@netronome.com
> >
> > [1] commit 1df21702873d ("mem: use address hint for mapping
> > hugepages")
> >
> > Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> > ---
>
> I understand the motivation, however this will lower the reliability of
> secondary process initialization.
Can you explain why?
It is very bad if we base the DPDK secondary process design on some predefined VA address base to be available.
Perhaps, the hinting could be improved by
> not trying to use the hint multiple times, but rather just once? I.e.
> if using hint succeeded - great, if not - try without one. Most of the time hint
> will work correctly, i think.
>
> --
> Thanks,
> Anatoly
next prev parent reply other threads:[~2019-03-28 8:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 20:21 Shahaf Shuler
2019-03-21 20:21 ` Shahaf Shuler
2019-03-27 5:36 ` Shahaf Shuler
2019-03-27 5:36 ` Shahaf Shuler
2019-03-27 11:49 ` Burakov, Anatoly
2019-03-27 11:49 ` Burakov, Anatoly
2019-03-28 8:45 ` Shahaf Shuler [this message]
2019-03-28 8:45 ` Shahaf Shuler
2019-03-28 10:26 ` Burakov, Anatoly
2019-03-28 10:26 ` Burakov, Anatoly
2019-03-31 8:43 ` [dpdk-dev] [PATCH v2] mem: limit use of address hint Shahaf Shuler
2019-03-31 8:43 ` Shahaf Shuler
2019-04-02 16:13 ` Burakov, Anatoly
2019-04-02 16:13 ` Burakov, Anatoly
2019-04-02 17:23 ` Alejandro Lucero
2019-04-02 17:23 ` Alejandro Lucero
2019-04-03 17:22 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-04-03 17:22 ` 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=AM0PR0502MB37950056006A83351B8FE929C3590@AM0PR0502MB3795.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=alejandro.lucero@netronome.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.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).