Re: [dpdk-dev] Ports not detected by IGB_UIO in DPDK 1.7.1 in QEMU_KVM environment

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Nov 07, 2014 at 11:26:08PM +0530, Manoj Viswanath wrote:
> Hi Bruce,
> 
> Please find my comment in lined.
> 
> On Fri, Nov 7, 2014 at 9:00 PM, Bruce Richardson <bruce.richardson@intel.com
> > wrote:
> 
> > On Fri, Nov 07, 2014 at 08:31:34PM +0530, Manoj Viswanath wrote:
> > > Hi Bruce,
> > >
> > > I was not doing anything specific for binding the NICs to IGB_UIO (like
> > > invoking "dpdk_nic_bind.py" script explicitly) when using my application
> > > with DPDK 1.6.0. The e1000 devices assigned via virt-manager to the VM
> > were
> > > automatically getting picked up and initialized by IGB_UIO within each
> > VM.
> > >
> > > The same is not working with DPDK 1.7.1 now.
> > >
> > > I tried exporting the "dpdk_nic_bind.py" script into my VM (running DPDK
> > > 1.7.1) and tried to check the status. The emulated devices were shown as
> > > neither bound to kernel nor to IGB_UIO as evident from below output:-
> > >
> > >
> > <--------------------------------------------------------------------------------------------------->
> > > Network devices using DPDK-compatible driver
> > > ============================================
> > > <none>
> > >
> > > Network devices using kernel driver
> > > ===================================
> > > 0000:00:03.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio
> > >
> > > Other network devices
> > > =====================
> > > 0000:00:04.0 '82540EM Gigabit Ethernet Controller' unused=igb_uio
> > > 0000:00:05.0 '82540EM Gigabit Ethernet Controller' unused=igb_uio
> > >
> > <--------------------------------------------------------------------------------------------------->
> > >
> > > When i tried to forcefully bind the NICs using the "--bind=igb_uio"
> > option
> >
> > Was there any output of the dpdk_nic_bind script? What does the output of
> > it with --status show afterwards?
> >
> > ​
> [MANOJ]​
> 
> ​Yes. Please refer below output:-
> ********************************************************************
> Network devices using DPDK-compatible driver
> ============================================
> 0000:00:04.0 '82540EM Gigabit Ethernet Controller' drv=igb_uio unused=
> 0000:00:05.0 '82540EM Gigabit Ethernet Controller' drv=igb_uio unused=
> 
> Network devices using kernel driver
> ===================================
> 0000:00:03.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio
> 
> Other network devices
> =====================
> <none>​
> ********************************************************************
> 
> ​However, when i start the DPDK application, i am getting the error log as
> indicated in earlier mail. ​
> 
> The difference with DPDK 1.6.1 is that at the same stage IGB_UIO has
> already bound the assigned devices without having to explicitly run the
> "dpdk_nic_bind.py". Please find below the application log when run with
> DPDK 1.6.0:-
> 
> ​********************************************************************
> Network devices using DPDK-compatible driver
> ============================================
> 0000:00:04.0 '82540EM Gigabit Ethernet Controller' drv=igb_uio unused=
> 0000:00:08.0 '82540EM Gigabit Ethernet Controller' drv=igb_uio unused=
> 
> Network devices using kernel driver
> ===================================
> 0000:00:03.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio
> 
> Other network devices
> =====================
> <none>
> ********************************************************************​
> 
> ​Kindly note that in both cases, logs have been taken after loading IGB_UIO
> prior to starting DPDK application. ​
> 
> ​[/MANOJ]​
> 
> Regards,

Ok, so it appears that after running dpdk_nic_bind to bind the devices to igb_uio
the differences between 1.6 and 1.7 are resolved for that part. The reason
why you explicitly need to bind the devices in 1.7 is due to this commit which
removes the pci id table from the igb_uio driver.

http://dpdk.org/browse/dpdk/commit/?id=629395b063e8278a05ea41908d1152fa68df098c

As for the other errors you are seeing, I'm not sure of the cause, though they
may be related to interrupt support for changes in link status. Can you perhaps
use a debugger and find out what the file descriptor in question refers to?

/Bruce