From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: add option to not store segment fd's Date: Fri, 29 Mar 2019 12:34:26 +0100 Message-ID: <1682850.JO3elT0QtZ@xps> References: <07f664c33ddedaa5dcfe82ecb97d931e68b7e33a.1550855529.git.anatoly.burakov@intel.com> <940ad1bd-8df5-5afb-e5e4-2f954a0a2686@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: David Marchand , dev , John McNamara , Marko Kovacevic , iain.barker@oracle.com, edwin.leung@oracle.com, maxime.coquelin@redhat.com To: "Burakov, Anatoly" Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 591222BF4 for ; Fri, 29 Mar 2019 12:34:30 +0100 (CET) In-Reply-To: <940ad1bd-8df5-5afb-e5e4-2f954a0a2686@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > 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?