On Wed, Oct 14, 2015 at 2:07 AM, Stephen Hemminger < stephen at networkplumber.org> wrote:
> On Thu, 1 Oct 2015 07:25:45 -0400 > Neil Horman <nhorman at tuxdriver.com> wrote: > > > On Wed, Sep 30, 2015 at 05:37:05PM +0200, Thomas Monjalon wrote: > > > 2015-09-30 10:52, Neil Horman: > > > > 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. > I am testing Thomas proposal (just moving the intr_init() call), else I will rebase this patch. -- David Marchand
