From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance Date: Sun, 27 Sep 2015 12:43:38 +0300 Message-ID: <20150927123914-mutt-send-email-mst@redhat.com> References: <56079527.3000802@cloudius-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" To: Vlad Zolotarov Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 5E9125939 for ; Sun, 27 Sep 2015 11:43:41 +0200 (CEST) Content-Disposition: inline In-Reply-To: <56079527.3000802@cloudius-systems.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sun, Sep 27, 2015 at 10:05:11AM +0300, Vlad Zolotarov wrote: > Hi, > I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on > Amazon EC2 instances with Enhanced Networking enabled. > The idea is to create a DPDK environment that doesn't require compiling > kernel modules (igb_uio). > However I was surprised to discover that uio_pci_generic refuses to work > with EN device on AWS: > > $ lspci > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01) > 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 > 00:03.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) > 00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) > 00:1f.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01) > > $ sudo ./dpdk/tools/dpdk_nic_bind.py -b uio_pci_generic 00:04.0 > Error: bind failed for 0000:00:04.0 - Cannot bind to driver uio_pci_generic > $dmesg > > --> snip <--- > [ 816.655575] uio_pci_generic 0000:00:04.0: No IRQ assigned to device: no support for interrupts? > > $ sudo lspci -s 00:04.0 -vvv > 00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) > Physical Slot: 4 > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Region 0: Memory at f3008000 (64-bit, prefetchable) [size=16K] > Region 3: Memory at f300c000 (64-bit, prefetchable) [size=16K] > Capabilities: [70] MSI-X: Enable- Count=3 Masked- > Vector table: BAR=3 offset=00000000 > PBA: BAR=3 offset=00002000 > Kernel modules: ixgbevf > > So, as we may see the PCI device doesn't have an INTX interrupt line > assigned indeed. It has an MSI-X capability however. > Looking at the uio_pci_generic code it seems to require the INTX: > > uio_pci_generic.c: line 74: probe(): > > if (!pdev->irq) { > dev_warn(&pdev->dev, "No IRQ assigned to device: " > "no support for interrupts?\n"); > pci_disable_device(pdev); > return -ENODEV; > } > > Is it a known limitation? Michael, could u, pls., comment on this? > > thanks, > vlad This is expected. uio_pci_generic forwards INT#x interrupts from device to userspace, but VF devices never assert INT#x. So it doesn't seem to make any sense to bind uio_pci_generic there. I think that DPDK should be fixed to not require uio_pci_generic for VF devices (or any devices without INT#x). If DPDK requires a place-holder driver, the pci-stub driver should do this adequately. See ./drivers/pci/pci-stub.c -- MST