From: Thomas Monjalon <thomas@monjalon.net>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>,
"Walker, Benjamin" <benjamin.walker@intel.com>,
sergio.gonzalez.monroy@intel.com, anatoly.burakov@intel.com
Cc: dev@dpdk.org
Subject: Re: Running DPDK as an unprivileged user
Date: Sun, 05 Nov 2017 01:17:33 +0100 [thread overview]
Message-ID: <2179627.cU6MQpMJOa@xps> (raw)
In-Reply-To: <6c6766f0-145e-9354-e275-d107d69173c3@intel.com>
Hi, restarting an old topic,
05/01/2017 16:52, Tan, Jianfeng:
> On 1/5/2017 5:34 AM, Walker, Benjamin wrote:
> >>> Note that this
> >>> probably means that using uio on recent kernels is subtly
> >>> broken and cannot be supported going forward because there
> >>> is no uio mechanism to pin the memory.
> >>>
> >>> The first open question I have is whether DPDK should allow
> >>> uio at all on recent (4.x) kernels. My current understanding
> >>> is that there is no way to pin memory and hugepages can now
> >>> be moved around, so uio would be unsafe. What does the
> >>> community think here?
>
> Back to this question, removing uio support in DPDK seems a little
> overkill to me. Can we just document it down? Like, firstly warn users
> do not invoke migrate_pages() or move_pages() to a DPDK process; as for
> the kcompactd daemon and some more cases (like compaction could be
> triggered by alloc_pages()), could we just recommend to disable
> CONFIG_COMPACTION?
We really need to better document the limitations of UIO.
May we have some suggestions here?
> Another side, how does vfio pin those memory? Through memlock (from code
> in vfio_pin_pages())? So why not just mlock those hugepages?
Good question. Why not mlock the hugepages?
next prev parent reply other threads:[~2017-11-05 0:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 20:41 Running DPDK as an unprivileged user Walker, Benjamin
2016-12-30 1:14 ` Stephen Hemminger
2017-01-02 14:32 ` Thomas Monjalon
2017-01-02 19:47 ` Stephen Hemminger
2017-01-03 22:50 ` Walker, Benjamin
2017-01-04 10:11 ` Thomas Monjalon
2017-01-04 21:35 ` Walker, Benjamin
2017-01-04 11:39 ` Tan, Jianfeng
2017-01-04 21:34 ` Walker, Benjamin
2017-01-05 10:09 ` Sergio Gonzalez Monroy
2017-01-05 10:16 ` Sergio Gonzalez Monroy
2017-01-05 14:58 ` Tan, Jianfeng
2017-01-05 15:52 ` Tan, Jianfeng
2017-11-05 0:17 ` Thomas Monjalon [this message]
2017-11-27 17:58 ` Walker, Benjamin
2017-11-28 14:16 ` Alejandro Lucero
2017-11-28 17:50 ` Walker, Benjamin
2017-11-28 19:13 ` Alejandro Lucero
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=2179627.cU6MQpMJOa@xps \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=benjamin.walker@intel.com \
--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 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.