Re: rte_eth_dev_configure fails on VM with e1000 drivers

[Marc Sune <marc.sune-kpkqNMk1I7M@public.gmane.org>]

Maybe useless but, I've also seen this error when trying to configure 
e1000's with more than 1 queue.

Sometimes the only way to see such (stupid) errors is to enable the 
DEBUG output from the driver:

marc@dpdk:~/dpdk/config$ git diff .
diff --git a/config/defconfig_x86_64-default-linuxapp-gcc 
b/config/defconfig_x86_64-default-linuxapp-gcc
index f11ffbf..9175954 100644
--- a/config/defconfig_x86_64-default-linuxapp-gcc
+++ b/config/defconfig_x86_64-default-linuxapp-gcc
@@ -122,7 +122,7 @@ CONFIG_RTE_LOG_LEVEL=8
  CONFIG_RTE_LOG_HISTORY=256
  CONFIG_RTE_LIBEAL_USE_HPET=n
  CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
-CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
+CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=y

@@ -158,11 +158,11 @@ CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
  #
  CONFIG_RTE_LIBRTE_EM_PMD=y
  CONFIG_RTE_LIBRTE_IGB_PMD=y
-CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_E1000_DEBUG_INIT=y
+CONFIG_RTE_LIBRTE_E1000_DEBUG_RX=y
  CONFIG_RTE_LIBRTE_E1000_DEBUG_TX=n
  CONFIG_RTE_LIBRTE_E1000_DEBUG_TX_FREE=n
-CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_E1000_DEBUG_DRIVER=y
  CONFIG_RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC=n

@all: would it make sense to be able to enable debug for non performance 
critical operations (so except for TX/RX) via an API calls/global variables?

Best regards
marc


On 29/04/14 11:28, B Gopikrishna wrote:
> Apologies for the delayed reply, we continued with 1 core to complete our work. But
> currently we would like to extend running the application with 2 core's and we are still unable to after following suggestions by
>   
> Thomas, the commit mentioned by you is already available as part of the DPDK code we compiled.
>   
> Tomasz, we tried with the port mask of 0x06, but this doesnot work either.
>   
> Any other suggestions or pointers to resolve the same would be of great help.
> Thankyou
>   
> Regards
> Gopi Krishna B
>
> -----Tomasz K <tomasz.kasowicz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: -----
> To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
> From: Tomasz K <tomasz.kasowicz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: 04/18/2014 06:07PM
> cc: B Gopikrishna <b.gopikrishna-/cgKlWMm3F8@public.gmane.org>, dev <dev-VfR2kkLFssw@public.gmane.org>
> Subject: Re: [dpdk-dev] rte_eth_dev_configure fails on VM with e1000 drivers
>
>
> Hi Gopi
>
> I recently run into the same problem when using 82576 with igb_uio on VM.
> The problem is not e1000 or igb. The problem is with the other network device managed by virtio-pci driver
>
>
> Notice that when application polls for ETH devices it prints out
> EAL:   probe driver: 1af4:1000 rte_virtio_pmd
> EAL:   0000:00:03.0 not managed by UIO driver, skipping
>
>
> So even though this NIC is not managed by igb_uio driver the app prints that driver used for it is rte_virtio_pmd.
> After setting up ETH devices app tries to set up tx/rx queues and it fails on port 0 (which is virtio)
>
>
> You can try and run the application with -p 0x6 instead of 0x3. This should mask out port0 from configuration
>
>
> Thanks
> Tomasz
>
>
> 2014-04-18 14:31 GMT+02:00 Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>:
>
> Hi,
>
> 2014-04-18 17:39, B Gopikrishna:
>
>> when I run the l3fwd application with the below command line, I am observing
>> the error "Cannot configure device: err=-22, port=0". The complete log is
>> posted below.
>
> Could you try to reproduce it with the git HEAD version?
> It may be fixed by this commit:
>          d73d8f3   timer: fix TSC frequency by not reading /proc/cpuinfo
>
> --
> Thomas
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>