From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 35579A05D3 for <public@inbox.dpdk.org>; Fri, 29 Mar 2019 12:34:33 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AEE0B2C28; Fri, 29 Mar 2019 12:34:31 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 591222BF4 for <dev@dpdk.org>; Fri, 29 Mar 2019 12:34:30 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DDF02220CF; Fri, 29 Mar 2019 07:34:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 29 Mar 2019 07:34:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=2etosWc+sTSz4/VykwubkiDAgbDXyINHzqY9KaJjz7Y=; b=qCuLp2CHuEKy AtIPCSBMdrSis3qrFua8LV23nj3fEmEzJcRUfwZ2v+s9pTAxCoaQto/p7h3c83Hj EU/BFX7Z4rzLPkNEE1/3K5C3flhJ+k8/pxRYotLTiTKPgyHqXjbLGkclG2FdQT18 VWC73ni1+2Tzg5xI8Vm6hdkgSPLtaZs= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=2etosWc+sTSz4/VykwubkiDAgbDXyINHzqY9KaJjz 7Y=; b=6PrMe38DO2ZlPaP/Sfht4N7r3a3SAy+JRRNVMhE0w947ee4NggxqxbWfb Ta1r9FQbZA2Rd1JcVRSkM6LowUKiQCFKb8ZKtOEc2HMK1y9sx2uQmSHJUOmEJyJd plnFAOw8zU9PbvfysswQNpYKJBYl8oSXtHcSkX427fKKYIrlI5kiZNfbXAgTKBCH rq0uQO3FdMCdGYG1mUP1KQGOTdGUiKJc4FRQKSOytkbJlcBbDEJduDqXwWo1ZmqJ C55wc+L+e+22GLRN0L7Jw45C+tivUd6BQff84CTzdiomQ/lZoXR8xMYgDz5Y2meT ZXHM5Uicuefd3NWwijgCUXGA75Ylg== X-ME-Sender: <xms:xAKeXAItQn-pC1HF2YgHi3mpV-OGG7IQSLbngtgzqhgw3OXPCyne0w> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkeejgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefgedrvddtfedrudekgeenucfr rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: <xmx:xAKeXLHpIie8jb5ihI3LOqZCia5PkywUiHJ-QIQtPm7ex1VyV2WIjA> <xmx:xAKeXPpWxNalyyfmdwY1_bYuu8wRm6gGyCX76G4ZC784QtNXORTcJg> <xmx:xAKeXB1h5ay9J87GYrZOqV4NdkyI_-oZdTkgR_g-AfsEdk0iL4yl8g> <xmx:xQKeXGYp9ecfechXZJXgH7AvocW7jsVKPnYttWZAVPZsgOFf_YPD6w> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E7871031A; Fri, 29 Mar 2019 07:34:27 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Burakov, Anatoly" <anatoly.burakov@intel.com> Cc: David Marchand <david.marchand@redhat.com>, dev <dev@dpdk.org>, John McNamara <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com>, iain.barker@oracle.com, edwin.leung@oracle.com, maxime.coquelin@redhat.com Date: Fri, 29 Mar 2019 12:34:26 +0100 Message-ID: <1682850.JO3elT0QtZ@xps> In-Reply-To: <940ad1bd-8df5-5afb-e5e4-2f954a0a2686@intel.com> References: <07f664c33ddedaa5dcfe82ecb97d931e68b7e33a.1550855529.git.anatoly.burakov@intel.com> <CAJFAV8x540Zv8r3iMm+-xbPpTrAaOjh+j4P_8vaXtRBUJW0sPw@mail.gmail.com> <940ad1bd-8df5-5afb-e5e4-2f954a0a2686@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] eal: add option to not store segment fd's X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190329113426.1UGEck1y4E3Ejbqov7pJV-T2TsbFwi8dWmwecYxP3mc@z> 29/03/2019 11:33, Burakov, Anatoly: > On 29-Mar-19 9:50 AM, David Marchand wrote: > > On Fri, Feb 22, 2019 at 6:12 PM Anatoly Burakov > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote: > > > > Due to internal glibc limitations [1], DPDK may exhaust internal > > file descriptor limits when using smaller page sizes, which results > > in inability to use system calls such as select() by user > > applications. > > > > While the problem can be worked around using --single-file-segments > > option, it does not work if --legacy-mem mode is also used. Add a > > (yet another) EAL flag to disable storing fd's internally. This > > will sacrifice compability with Virtio with vhost-backend, but > > at least select() and friends will work. > > > > [1] https://mails.dpdk.org/archives/dev/2019-February/124386.html > > > > > > Sorry, I am a bit lost and I never took the time to look in the new > > memory allocation system. > > This gives the impression that we are accumulating workarounds, between > > legacy-mem, single-file-segments, now no-seg-fds. > > Yep. I don't like this any more than you do, but i think there are users > of all of these, so we can't just drop them willy-nilly. My great hope > was that by now everyone would move on to use VFIO so legacy mem > wouldn't be needed (the only reason it exists is to provide > compatibility for use cases where lots of IOVA-contiguous memory is > required, and VFIO cannot be used), but apparently that is too much to > ask :/ > > > > > Iiuc, everything revolves around the need for per page locks. > > Can you summarize why we need them? > > The short answer is multiprocess. We have to be able to map and unmap > pages individually, and for that we need to be sure that we can, in > fact, remove a page because no one else uses it. We also need to store > fd's because virtio with vhost-user backend needs them to work, because > it relies on sharing memory between processes using fd's. It's a pity adding an option to workaround a limitation of a corner case. It adds complexity that we will have to support forever, and it's even not perfect because of vhost. Might there be another solution?