[dpdk-dev] Unable to bind Virtio_pci in DPDK1.7
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dey, Souvik > Sent: Friday, May 29, 2015 1:22 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Unable to bind Virtio_pci in DPDK1.7 > > Hi All, > I am currently facing a weird issue where I am not able to > bind the > virtio_pci device to igb_uio in DPDK1.7 on QEMU/KVM. I can see there are > two fold issues. > 1.The pci_unbind.py script where the virt_path is removed from 1.6 to 1.7 > version due to which the initial status is not able to show any interface > name. > > Network devices using DPDK-compatible driver > > > > Network devices using kernel driver > === > :00:03.0 'Virtio network device' if= drv=virtio-pci > unused=virtio_pci,igb_uio > :00:04.0 'Virtio network device' if= drv=virtio-pci > unused=virtio_pci,igb_uio > :00:05.0 'Virtio network device' if= drv=virtio-pci > unused=virtio_pci,igb_uio > :00:06.0 'Virtio network device' if= drv=virtio-pci > unused=virtio_pci,igb_uio > > Other network devices > = > > > > 2. After correcting the above issue , I am stuck where the interface is > failing > to bind to igb_uio. I tried to bind the interface manually to igb_uio but I > am > getting the following error > > lspci -k > 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device > Subsystem: Red Hat, Inc Device 0001 > Kernel modules: virtio_pci > > echo :00:05.0 > /sys/bus/pci/drivers/igb_uio/bind > -bash: echo: write error: No such device > > Due to this the bind fails and the virtio_pmd is not able to take and my app > is > not coming up. > EAL: PCI device :00:03.0 on NUMA socket -1 > EAL: probe driver: 1af4:1000 rte_virtio_pmd > EAL: :00:06.0 not managed by UIO driver, skipping > EAL: Error - exiting with code: 1 > Cause: No Ethernet ports - bye > > I see lots of email threads on similar issue but none had the final > conclusion. > So can someone guide me on how to proceed further or get out of this error. > Suggest you use the dpdk_nic_bind.py in recently released dpdk package or get it from dpdk.org repo. I use it to bind virtio-pci device to igb_uio and after that, I bind it reversely from igb_uio back to virtio-pci again. It works, don't find any issue. Thanks Changchun
[dpdk-dev] Unable to bind Virtio_pci in DPDK1.7
Hi All, I am currently facing a weird issue where I am not able to bind the virtio_pci device to igb_uio in DPDK1.7 on QEMU/KVM. I can see there are two fold issues. 1.The pci_unbind.py script where the virt_path is removed from 1.6 to 1.7 version due to which the initial status is not able to show any interface name. Network devices using DPDK-compatible driver Network devices using kernel driver === :00:03.0 'Virtio network device' if= drv=virtio-pci unused=virtio_pci,igb_uio :00:04.0 'Virtio network device' if= drv=virtio-pci unused=virtio_pci,igb_uio :00:05.0 'Virtio network device' if= drv=virtio-pci unused=virtio_pci,igb_uio :00:06.0 'Virtio network device' if= drv=virtio-pci unused=virtio_pci,igb_uio Other network devices = 2. After correcting the above issue , I am stuck where the interface is failing to bind to igb_uio. I tried to bind the interface manually to igb_uio but I am getting the following error lspci -k 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device Subsystem: Red Hat, Inc Device 0001 Kernel modules: virtio_pci echo :00:05.0 > /sys/bus/pci/drivers/igb_uio/bind -bash: echo: write error: No such device Due to this the bind fails and the virtio_pmd is not able to take and my app is not coming up. EAL: PCI device :00:03.0 on NUMA socket -1 EAL: probe driver: 1af4:1000 rte_virtio_pmd EAL: :00:06.0 not managed by UIO driver, skipping EAL: Error - exiting with code: 1 Cause: No Ethernet ports - bye I see lots of email threads on similar issue but none had the final conclusion. So can someone guide me on how to proceed further or get out of this error. -- Regards, Souvik
[dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline
The confusion is due to whether you consider stats as a library feature or Debug feature. Mostly log levels are considered as debug features in the production system and controlled system wide flag not per library flags. While statistics could be considered as a library feature which could be turned on and off depends on the application needs. I am with Cristian to have per library feature configuration flag for statistics. Regards Kannan Babu -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dumitrescu, Cristian Sent: Friday, May 29, 2015 12:56 AM To: Rajagopalan Sivaramakrishnan; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline Hi Raja, Thanks for your input. I think we have the following options identified so far for stats collection configuration: 1. Stats configuration through the RTE_LOG_LEVEL 2. Single configuration flag global for all DPDK libraries 3. Single configuration flag per DPDK library It would be good if Thomas and Stephen, as well as others, would reply with their preference order. My personal preference order is: 3., 2., 1., but I can work with any of the above that is identified by the majority of the replies. My goal right now is reaching a conclusion on this item as soon as we can. Regards, Cristian > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rajagopalan > Sivaramakrishnan > Sent: Wednesday, May 27, 2015 11:45 PM > To: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for > librte_pipeline > > > > > You also reiterate that you would like to have the stats always enabled. > You > > can definitely do this, it is one of the available choices, but why > > not also accommodate the users that want to pick the opposite > > choice? Why force apps to spend cycles on stats if the app either > > does not want these > counters > > (library counters not relevant for that app, maybe the app is only > interested > > in maintaining some other stats that it implements itself) or do not > > want them anymore (maybe they only needed them during debug phase), etc? > > Jay asked this question, and I did my best in my reply to describe > > our motivation (http://www.dpdk.org/ml/archives/dev/2015- > May/017992.html). > > Maybe you missed that post, it would be good to get your reply on > > this one too. > > > > I want to see DPDK get out of the config madness. > > This is real code, not an Intel benchmark special. > > > I agree that statistics will definitely be required in most real-world > production environments and the overhead from per-core stats gathering > will be minimal if the data structures are such that CPU cache > thrashing is avoided. > However, if there are scenarios where it is desirable to turn stats > off, I think we can live with a config option. > I am not comfortable with using the log level to enable/disable > statistics as they are not really related. A separate config option > for stats collection seems like a reasonable compromise. > > Raja
