From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
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 <dev@dpdk.org>; Wed, 14 Oct 2015 02:06:55 +0200 (CEST)
Received: by pacex6 with SMTP id ex6so35422655pac.3
 for <dev@dpdk.org>; Tue, 13 Oct 2015 17:06:55 -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=UbNGCxtgZ2RWcOsLPlzRK8Hh347UitmCFpocDxpfnPo=;
 b=j50lAmdwzGvBfEj5KOO/jnFkQp8h67WpVnPcwqkchgZI9bU+g69WC9SqKJL1wCQsWL
 W9faK5anDASNtQ3UYwagLrZilYWGiVLlFv7TVW99lYxOxNiVgl5m0NXe0Jk55SF4H4XQ
 oO80G1vYwi5P5DJY4509kFDZfpQ0cT1kJ7b2A77EDwgAqZ4iaKx2NADJS4M2VIoY9qj5
 1P1PWCZzQsWd+I3aEWetRv8kK3Gpj8wBkXg4XQnO3koma04CNsHuZoiy16NnNwEhKDrT
 ol6fqT2sUsTsIG4lwqO13MTPgjFa9TfRbROZGq5B1prXMCNuZmmaoD9CgHLpGhSVRy36
 Fj4Q==
X-Gm-Message-State: ALoCoQk2VsJ6DIJwuD7Wz6O49ecrruJ0v7/VbiR99u7OGmHcfZQRV6xee/DXcta7Fp+HjHqagB+u
X-Received: by 10.66.162.168 with SMTP id yb8mr286639pab.48.1444781214962;
 Tue, 13 Oct 2015 17:06:54 -0700 (PDT)
Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by smtp.gmail.com with ESMTPSA id vm6sm5964509pbc.8.2015.10.13.17.06.54
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 13 Oct 2015 17:06:54 -0700 (PDT)
Date: Tue, 13 Oct 2015 17:07:06 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Neil Horman <nhorman@tuxdriver.com>
Message-ID: <20151013170706.376bbdd8@xeon-e3>
In-Reply-To: <20151001112545.GC4537@hmsreliant.think-freely.org>
References: <CALwxeUuQtv685KnbmpZKCPkrAqmjLs558xeCW7c=-TPTsB423w@mail.gmail.com>
 <CALwxeUuiFpPKeSOh11ANmJwbkTi3fSO6AVAi-TLWBNs0nTP66g@mail.gmail.com>
 <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
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2015 00:06:56 -0000

On Thu, 1 Oct 2015 07:25:45 -0400
Neil Horman <nhorman@tuxdriver.com> 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 <nhorman@tuxdriver.com> 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.