From: Stephen Hemminger <stephen@networkplumber.org>
To: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Cc: "Tan, Jianfeng" <jianfeng.tan@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] pci: force address of mappings in secondary process
Date: Tue, 11 Jul 2017 13:00:14 -0700 [thread overview]
Message-ID: <20170711130014.402463a9@xeon-e3> (raw)
In-Reply-To: <3f48cbd3-1e60-5a92-3929-7ba06e3cc69c@intel.com>
On Tue, 11 Jul 2017 12:35:39 +0100
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> wrote:
> On 11/07/2017 02:56, Tan, Jianfeng wrote:
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen
> >> Hemminger
> >> Sent: Tuesday, July 11, 2017 9:13 AM
> >> To: dev@dpdk.org
> >> Cc: Stephen Hemminger
> >> Subject: [dpdk-dev] [RFC] pci: force address of mappings in secondary
> >> process
> >>
> >> The PCI memory resources in the secondary process should be in
> >> the exact same location as the primary process. Otherwise
> >> there is a risk of a stray pointer.
> >>
> >> Not sure if this is right, but it looks like a potential
> >> problem.
> >>
> >> ---
> >> lib/librte_eal/common/eal_common_pci_uio.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/lib/librte_eal/common/eal_common_pci_uio.c
> >> b/lib/librte_eal/common/eal_common_pci_uio.c
> >> index 367a6816dcb8..2156b1a436c4 100644
> >> --- a/lib/librte_eal/common/eal_common_pci_uio.c
> >> +++ b/lib/librte_eal/common/eal_common_pci_uio.c
> >> @@ -77,7 +77,7 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
> >>
> >> void *mapaddr = pci_map_resource(uio_res-
> >>> maps[i].addr,
> >> fd, (off_t)uio_res->maps[i].offset,
> >> - (size_t)uio_res->maps[i].size, 0);
> >> + (size_t)uio_res->maps[i].size,
> >> MAP_FIXED);
> >> /* fd is not needed in slave process, close it */
> >> close(fd);
> >> if (mapaddr != uio_res->maps[i].addr) {
> >> --
> >> 2.11.0
> > +1 for this RFC. I also once encounter such problem, and I use the same way to solve it. The addr parameter of mmap() syscall is only a hint instead of a must even the VMA is not occupied yet.
> >
> > Thanks,
> > Jianfeng
>
> How do you know the VMA is not occupied?
>
> I think the risk here is that the dynamic linker loaded some shared
> library in that VMA, and forcing MAP_FIXED is not a safe solution.
> What I have observed is that Linux will return a different VMA than the
> one hinted when there is already a mapping in the requested/hinted VMA.
>
> I reckon this is a similar issue as we have with the multi-process model
> when we do not get the VMA requested for the huge-pages.
> AFAIK we do not have a robust solution for this issue other than restart
> the program and hope the dynamic linker does not map anything in the VMA
> ranges that we need to map from the primary. This is also assuming that
> the application does not allocate memory and maps things before calling
> eal_init as it could potentially use VMA ranges that we need in the
> secondary process.
>
> The proposal for new secondary process model would solve these issues:
> http://dpdk.org/ml/archives/dev/2017-May/066147.html
>
> Thanks,
> Sergio
That proposal defeats some of the isolation of secondary process model.
The idea is that secondary could be built separately. It is also overly
complex and would make a somewhat fragile part of the DPDK, more difficult.
next prev parent reply other threads:[~2017-07-11 20:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-11 1:12 Stephen Hemminger
2017-07-11 1:56 ` Tan, Jianfeng
2017-07-11 11:35 ` Sergio Gonzalez Monroy
2017-07-11 20:00 ` Stephen Hemminger [this message]
2017-07-12 7:24 ` Sergio Gonzalez Monroy
2017-07-12 2:45 ` Tan, Jianfeng
2017-07-12 7:31 ` Sergio Gonzalez Monroy
2017-07-12 8:58 ` Tan, Jianfeng
2019-01-23 19:21 ` Ferruh Yigit
2019-01-23 20:37 ` Stephen Hemminger
2019-01-28 9:59 ` Burakov, Anatoly
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=20170711130014.402463a9@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=sergio.gonzalez.monroy@intel.com \
/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).