From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by dpdk.org (Postfix) with ESMTP id F2AD48DA6 for ; Wed, 30 Sep 2015 19:26:39 +0200 (CEST) Received: by padhy16 with SMTP id hy16so46489518pad.1 for ; Wed, 30 Sep 2015 10:26:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=4nugB7dL6X+Gtv3dbO8qE5obl9rwfVAYKo2rCx3CUts=; b=IAUXQ+1g5yrY3/+MXpbxuCbx5yshBpU861O37cs+iIP85UXHkx6Y/bD6Ik3eUesE9k /nluedk1ICGyZfEU15cVj5hV9AT2Wc8MzdIgioQeKEOV09lh/zZxaS4R0KAYOe+3tKZg seKHxFW+vf+lWeTpG6hg70YeHysSWylWfGW9Ta3sesVwLC/h+9yLdi2UflEdrB+wfMuZ fF1yeKCvEcExKyvPJMcfArYErtBhHzvKoWyYFrbmGob0PAZVzb6Qv1rmHpkCQBfoMJGY BzETmwAF8z4N8j9WmnFddCExGXra+xmsjd0wz1D3LhnEcZXCA1xUJfhouzzxe7AC3cgB VyWg== X-Gm-Message-State: ALoCoQl93A62sCuWelnZtfgHnDejYyvkawQ6ZKZ+5tI3fCL5ug/aXtpjfqVER42pZL19KPEf7fKB X-Received: by 10.68.248.102 with SMTP id yl6mr6334785pbc.66.1443633999189; Wed, 30 Sep 2015 10:26:39 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id zc4sm1813591pbb.24.2015.09.30.10.26.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 10:26:39 -0700 (PDT) Date: Wed, 30 Sep 2015 10:26:47 -0700 From: Stephen Hemminger To: Thomas Monjalon Message-ID: <20150930102647.5bfd9a12@urahara> In-Reply-To: <2615920.hxcAs4lYm6@xps13> References: <20150930145202.GE32524@hmsreliant.think-freely.org> <2615920.hxcAs4lYm6@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: change io privilege level as early as possible X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 17:26:40 -0000 On Wed, 30 Sep 2015 17:37:05 +0200 Thomas Monjalon wrote: > 2015-09-30 10:52, Neil Horman: > > On Wed, Sep 30, 2015 at 10:28:53AM +0200, David Marchand wrote: > > > On Tue, Sep 29, 2015 at 9:25 PM, Stephen Hemminger < > > > stephen@networkplumber.org> wrote: > > > > > > > On Tue, 10 Mar 2015 09:14:28 -0400 > > > > Neil Horman wrote: > > > > > I don't see how this works for all cases. The constructor is called > > > > once when > > > > > the library is first loaded. What if you have multiple independent > > > > (i.e. not > > > > > forked children) processes that are using the dpdk in parallel? Only the > > > > > process that triggered the library load will have io permissions set > > > > > appropriately. I think what you need is to have every application that > > > > expects > > > > > to call through the transmit path or poll the receive path call iopl, > > > > which I > > > > > think speaks to having this requirement documented, so each application > > > > can call > > > > > iopl prior to calling fork/daemonize/etc. > > > > > > > > > > > > > I am still seeing this problem with DPDK 2.0 and 2.1. > > > > It seems to me that doing the iopl init in eal_init is the only safe way. > > > > Other workaround is to have application calling iopl_init before eal_init > > > > but that kind of violates the current method of all things being > > > > initialized by eal_init > > > > > > Putting it in the virtio pmd constructor is my preferred solution and we > > > don't need to pollute the eal for virtio (specific to x86, btw). > > > > Preferred solution or not, you can't just call iopl from the constructor, > > because not all process will get appropriate permissions. It needs to be called > > by every process. What Stephen is saying is that your solution has use cases > > for which it doesn't work, and that needs to be solved. > > I think it may be solved by calling iopl in the constructor. > We just need an extra call in rte_virtio_pmd_init() to detect iopl failures. > We can also simply move rte_eal_intr_init() after rte_eal_dev_init(). > Please read my previous post on this topic: > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/14761/focus=22341 > > About the multiprocess case, I don't see the problem as the RX/TX and interrupt > threads are forked in the rte_eal_init() context which should call iopl even in > secondary processes. Another alternative is to use ioperm to give access to certain regions. But ioperm does not inherit to other threads, therefore it required some code on startup to execute the syscall on each EAL thread.