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.
