From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id 0E44E11F5 for ; Wed, 30 Sep 2015 17:38:13 +0200 (CEST) Received: by wicfx3 with SMTP id fx3so67939837wic.0 for ; Wed, 30 Sep 2015 08:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=xeS04BgdETAi3fc9kWuwg2AxUlF/9Bv2jiQkY1QWVEw=; b=GstBzovyUnhTWYqhZfk7wj9zDn5Ooo9EnSCvROxNhht8DalN0jZJxH27rOvwSN7krl AMtTee1gu+ZXq+Qdal7EWpRk54wtLETWli0TJwZ5itTYG8qhEyBoXDA5cfAni5oVGzNp F3HZpene6n2/PNb8NJhTJJoK7m/Qo6CAUtODMll1jbN73zi5CHRTeHjs6v2aEQ/eRyKZ hXMYKExuOuuFg2Cz6ve9C1bAld2neCO+gqSTEpmHHr7YqMCDEL2VMV2QDDYrmBcSod9l fQP4841iVXgzH2L1CHD5Be3hEmsnBpi6uX+pfSFh4MvLGWVa9+C7kFILb+51ExAtJiAt 2gzA== X-Gm-Message-State: ALoCoQk9WNOPtnnQ4Q1BoJm5gcHBOkA0PITxXBdS5zv/uA9PfUxKC53OsYnzvJwqX8LZv3b09JFC X-Received: by 10.180.205.206 with SMTP id li14mr5836743wic.76.1443627492822; Wed, 30 Sep 2015 08:38:12 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id kr10sm1262026wjc.25.2015.09.30.08.38.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 08:38:12 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Wed, 30 Sep 2015 17:37:05 +0200 Message-ID: <2615920.hxcAs4lYm6@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20150930145202.GE32524@hmsreliant.think-freely.org> References: <20150930145202.GE32524@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 15:38:13 -0000 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.