On Fri, 6 Mar 2015 03:41:25 +0000 "Ouyang, Changchun" <changchun.ouyang at intel.com> wrote:
> > > > -----Original Message----- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen > > Hemminger > > Sent: Friday, March 6, 2015 8:45 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH 1/2] virtio: initialize iopl when device is > > initialized > > > > The virtio driver needs to use in/out instructions therefore it must > > initialize > > using iopl(2) system call. The problem is that virtio initialization > > happens very > > early, and any application that uses daemon() or calls eal_init later in > > another > > context will fail. > > > > The fix is to move the iopl into rte_eal_init. > > > > Why need move virtio specific code into rte_eal_init? > thanks > Changchun > The issue is that virtio has no place it can do iopl() and have the IRQ thread work. It only shows up on real code where application is daemon, not in a toy demo or test application. Right now: gcc start rte_virtio_pmd_init iopl main daemon fork fork Process is now child of init not original process rte_eal_init fork (pthread) for irq thread irq thread (no iopl permssion) program start rte_pmd_virtio_configure So the only place where iopl() can be done in the proper context so that the IRQ (and other helper threads in future) have the correct permissions is in eal_init.