From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH 2/2] virtio: change io privilege level as early as possible Date: Tue, 13 Oct 2015 17:07:06 -0700 Message-ID: <20151013170706.376bbdd8@xeon-e3> References: <20150930145202.GE32524@hmsreliant.think-freely.org> <2615920.hxcAs4lYm6@xps13> <20151001112545.GC4537@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Neil Horman Return-path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by dpdk.org (Postfix) with ESMTP id A23568D9D for ; Wed, 14 Oct 2015 02:06:55 +0200 (CEST) Received: by pacex6 with SMTP id ex6so35422655pac.3 for ; Tue, 13 Oct 2015 17:06:55 -0700 (PDT) In-Reply-To: <20151001112545.GC4537@hmsreliant.think-freely.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 1 Oct 2015 07:25:45 -0400 Neil Horman wrote: > On Wed, Sep 30, 2015 at 05:37:05PM +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. > > > > I'm not talking about secondary processes here (i.e. processes forked from a > parent that was the process which initialized the dpdk). I'm referring to two > completely independent processes, both of which link to and use the dpdk. > > Though I think we're saying the same thing. When you say 'constructor' above, > you don't mean 'constructor' in the strict sense, but rather the pmd init > routine (the one called from rte_eal_vdev_init and rte_eal_dev_init). If this > is the case, then yes, that works fine, since each process linking to the DPDK > will enter those routines and call iopl. In fact, if thats the case, then no > call is needed in the constructor at all. I think this patch should be rebased and resubmitted for 2.2. It fixes a real problem (virtio link state). The driver changed directory and the the patch could be redone to minimize changes.