From: Alejandro Lucero <alejandro.lucero@netronome.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "Stojaczyk, DariuszX" <dariuszx.stojaczyk@intel.com>,
dev <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] memory: do not use base-virtaddr in secondary processes
Date: Tue, 19 Jun 2018 11:23:34 +0100 [thread overview]
Message-ID: <CAD+H991hSrpB4T8Fcm-umj_Hv4XC5FZVuhXqHZ9f8sxUKLZzwg@mail.gmail.com> (raw)
In-Reply-To: <a59b9b56-7edf-03f6-85ec-faa3a533dbf7@intel.com>
On Tue, Jun 19, 2018 at 10:24 AM, Burakov, Anatoly <
anatoly.burakov@intel.com> wrote:
> On 18-Jun-18 9:12 PM, Stojaczyk, DariuszX wrote:
>
>>
>>
>> -----Original Message-----
>>> From: Alejandro Lucero [mailto:alejandro.lucero@netronome.com]
>>> Sent: Monday, June 18, 2018 9:33 PM
>>>
>>> On Mon, Jun 18, 2018 at 8:03 PM, Stojaczyk, DariuszX
>>> <dariuszx.stojaczyk@intel.com <mailto:dariuszx.stojaczyk@intel.com> >
>>> wrote:
>>>
>>> Can you point me out to an NFP guide or some code that describes
>>> this in more detail?
>>>
>>>
>>>
>>> As I said, I'm working on a RFC. I will send something shortly. But I
>>> could give
>>> you an advance: the hugepages needs to be mapped below certain virtual
>>> address, 1TB, and I'm afraid that includes the primary and also the
>>> secondary processes. At least if any process can send or receive packets
>>> to/from a NFP.
>>>
>>>
>>>
>> Thanks, I'm pretty sure we're safe, then.
>>
>>
>>> If we're talking about base-virtaddr for hugepages, then that's
>>> always
>>> inherited from the primary process, regardless of what base-virtaddr is
>>> supplied to the secondary.
>>>
>>>
>>>
>>>
>>> But, is not your patch avoiding to use that base-virtaddr for secondary
>>> processes?
>>>
>>
>> I see now that the patch name is slightly misleading. Maybe I shouldn’t
>> pick such a catchy title. Let me clarify: As of DPDK 18.05, --base-virtaddr
>> param for secondary process applications only affects that shadow memseg
>> metadata that's not useful for anyone, but can still do a lot of harm.
>> Hugepage memory in secondary processes is always mapped to the same
>> addresses the primary process uses.
>>
>> D.
>>
>>
> Hi Alejandro,
>
> To solve this problem, one possible approach would be to have maximum VA
> address, and allocate memory downwards, rather than upwards. Is that by any
> chance approximate contents of your RFC? :)
>
>
Hi Anatoly,
There's a lot of space below 1TB, but this specific upper limit is just in
the NFP case. My RFC will propose a generic solution assuming there could
be other devices in the future, and not just NIC devices, which could have
also some sort of limitation. The problem is, those devices limitations can
not be known at memory initialization time, so some sort of check is
required afterwards, once the devices have been proved and initialised.
> --
> Thanks,
> Anatoly
>
next prev parent reply other threads:[~2018-06-19 10:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 19:53 [dpdk-stable] " Dariusz Stojaczyk
2018-06-18 17:21 ` [dpdk-stable] [dpdk-dev] " Alejandro Lucero
2018-06-18 19:03 ` Stojaczyk, DariuszX
2018-06-18 19:33 ` Alejandro Lucero
2018-06-18 20:12 ` Stojaczyk, DariuszX
2018-06-19 9:24 ` Burakov, Anatoly
2018-06-19 10:23 ` Alejandro Lucero [this message]
2018-06-19 10:27 ` Burakov, Anatoly
2018-06-19 11:48 ` Alejandro Lucero
2018-06-19 9:21 ` [dpdk-stable] " Burakov, Anatoly
2018-07-12 22:08 ` [dpdk-stable] [dpdk-dev] " 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=CAD+H991hSrpB4T8Fcm-umj_Hv4XC5FZVuhXqHZ9f8sxUKLZzwg@mail.gmail.com \
--to=alejandro.lucero@netronome.com \
--cc=anatoly.burakov@intel.com \
--cc=dariuszx.stojaczyk@intel.com \
--cc=dev@dpdk.org \
--cc=stable@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).