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). -- David Marchand
