[dpdk-dev] [PATCH 2/2] virtio: change io privilege level as early as possible

[Neil Horman]

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 at networkplumber.org> wrote:
> > > 
> > > > On Tue, 10 Mar 2015 09:14:28 -0400
> > > > Neil Horman <nhorman at 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.

Neil