From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 04DB81B2FA for ; Sun, 5 Nov 2017 01:17:37 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3EF2D20814; Sat, 4 Nov 2017 20:17:36 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 04 Nov 2017 20:17:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=otH2EAl3um0TTPUvacJfycDHTc nK4K0Q7qrIvGNuJ3Q=; b=j/G8/mh5p/IQfHl5QP1I6GEFOi0hxDDBgx+JNovVyS mqB1GfwoZywRt16QdA7UM+5ivot/1bxm7+V4bkKbmIkbZbdoEg8k/xYoVSSG4+fK CS9bNLIIw32taw1+5ajFXETxm8xDpPFqGqt1k5EhYYVhLvPBcYhMZMs0V9weC6X+ o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=otH2EA l3um0TTPUvacJfycDHTcnK4K0Q7qrIvGNuJ3Q=; b=ScdkD106zQ+lzPezPTmIKp wXCNELShesySSm4ACtegQgJCskYviu7lKFc+Lnh7mm1P2pfTxGeii3XUkOPcGxdU CXPO+VRJyCeG1bbajIqWW/biIgofiYz+C4xh/y5HdZCrkstf19D2y00cmC+pjSY9 /JUG3WlKlmWCGNnDvRNrQERhJ69wnPxveFbvJRX6W35R3BSLFTHju8GNFBBM8MbS 9d/fVKolDCYHK7E9j1IJenSRNo4cFePlz0xN/ZvtgvOX3FvdQqjjeDG4L/BS8MLU CQ9YgJm+TayRvmjghVzrr/tXSPMIsvfUkbgAFzmjEJDLK8cjgL564ucyq+A7FVNg == X-ME-Sender: Received: from xps.localnet (32.16.136.77.rev.sfr.net [77.136.16.32]) by mail.messagingengine.com (Postfix) with ESMTPA id E062624E7F; Sat, 4 Nov 2017 20:17:35 -0400 (EDT) From: Thomas Monjalon To: "Tan, Jianfeng" , "Walker, Benjamin" , sergio.gonzalez.monroy@intel.com, anatoly.burakov@intel.com Cc: dev@dpdk.org Date: Sun, 05 Nov 2017 01:17:33 +0100 Message-ID: <2179627.cU6MQpMJOa@xps> In-Reply-To: <6c6766f0-145e-9354-e275-d107d69173c3@intel.com> References: <1483044080.11975.1.camel@intel.com> <1483565664.9482.3.camel@intel.com> <6c6766f0-145e-9354-e275-d107d69173c3@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Running DPDK as an unprivileged user X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 00:17:38 -0000 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?