DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Deme <odeme@druidsoftware.com>
To: "Ouyang, Changchun" <changchun.ouyang@intel.com>,
	 "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] freeze with dpdk-2.0.0
Date: Wed, 15 Apr 2015 10:49:07 +0100	[thread overview]
Message-ID: <552E3413.7050708@druidsoftware.com> (raw)
In-Reply-To: <F52918179C57134FAEC9EA62FA2F962511ABED7C@shsmsx102.ccr.corp.intel.com>

Hi Changchun,

I confirm that blacklisting the first two network interfaces solve the 
problem.
Just to be clear, is it the case that it is not possible to have a DPDK 
application acquiring selectively virtio network devices without using 
the blacklisting (-b) option?

It seems a bit clumsy to have the application being configured with all 
network interfaces to be bound to DPDK.

Thanks,
Olivier.



On 15/04/15 04:45, Ouyang, Changchun wrote:
> Hi Oliver
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Deme
>> Sent: Wednesday, April 15, 2015 1:16 AM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] freeze with dpdk-2.0.0
>>
>> Hi,
>>
>> I am trying to use DPDK-2.0.0 on Fedora 20 running in a qemu virtual machine.
>> After loading the uio and igb_uio module and setting up hugepages, I try to
>> run the helloworld demo application.
>> As soon as the helloworld displays the "hello from core 1, hello from core 0"
>> messages, I loose all network connectivity to the VM.
>>
>> If I try to run the helloworld application remotely the output freezes after
>> the following:
>> # ./build/helloworld -c 3 -n 2
>> EAL: Detected lcore 0 as core 0 on socket 0
>> EAL: Detected lcore 1 as core 0 on socket 0
>> EAL: Detected lcore 2 as core 0 on socket 0
>> EAL: Detected lcore 3 as core 0 on socket 0
>> EAL: Support maximum 128 logical core(s) by configuration.
>> EAL: Detected 4 lcore(s)
>> EAL: VFIO modules not all loaded, skip VFIO support...
>> EAL: Setting up memory...
>> EAL: Ask a virtual area of 0x7000000 bytes
>> EAL: Virtual area found at 0x7f273be00000 (size = 0x7000000)
>> EAL: Ask a virtual area of 0x200000 bytes
>> EAL: Virtual area found at 0x7f273ba00000 (size = 0x200000)
>> EAL: Ask a virtual area of 0x200000 bytes
>> EAL: Virtual area found at 0x7f273b600000 (size = 0x200000)
>> EAL: Ask a virtual area of 0xc00000 bytes
>> EAL: Virtual area found at 0x7f273a800000 (size = 0xc00000)
>> EAL: Requesting 64 pages of size 2MB from socket 0
>> EAL: TSC frequency is ~1995193 KHz
>> EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using
>> unreliable clock cycles !
>> EAL: Master lcore 0 is ready (tid=449e9900;cpuset=[0])
>> PMD: ENICPMD trace: rte_enic_pmd_init
>> EAL: lcore 1 is ready (tid=3a7ff700;cpuset=[1])
>>
>>
>> If I try to restart the network services, I get the error from syslog:
>> BUG: soft lockup - CPU#2 stuck for 22s!
>>
>>
>> The network devices exposed to the VM are 2 BCM5719 interfaces + 2
>> 82599ES interfaces:
>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
>> Gigabit Ethernet PCIe (rev 01)
>> 02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
>> Gigabit Ethernet PCIe (rev 01)
>> 0d:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
>> Network Connection (rev 01)
>> 0d:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
>> Network Connection (rev 01)
>>
>>
>> Within the VM, lspci shows:
>> 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
>> 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
>> 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
>> 00:06.0 Ethernet controller: Red Hat, Inc Virtio network device
>>
>>
>> After loading the kernel modules, I bind the interfaces to DPDK with:
>> /root/dpdk-2.0.0/tools/dpdk_nic_bind.py --bind=igb_uio 00:05.0
>> /root/dpdk-2.0.0/tools/dpdk_nic_bind.py --bind=igb_uio 00:06.0
>>
>> Would you know what is causing this?
>>
> Maybe you can try with "--b 00:03.0 00:04.0" to force dpdk not to grab these 2 virtio devices
> To see if this issue is resolved.
>
> For virtio dev, dpdk doesn't depend on uio/igb_uio any more after the single virtio,
> It will also grab the virtio device to use it even without uio module except for you specify it into black-list.
>
> Thanks
> Changchun
>

-- 
	*Olivier Demé*
*Druid Software Ltd.*
*Tel: +353 1 202 1831*
*Email: odeme@druidsoftware.com <mailto:odeme@druidsoftware.com>*
*URL: http://www.druidsoftware.com*
Druid Software: Monetising enterprise small cells solutions.


Druid_Footer_Logo

  reply	other threads:[~2015-04-15  9:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14 17:15 Olivier Deme
2015-04-15  3:45 ` Ouyang, Changchun
2015-04-15  9:49   ` Olivier Deme [this message]
2015-04-16  3:28     ` Ouyang, Changchun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=552E3413.7050708@druidsoftware.com \
    --to=odeme@druidsoftware.com \
    --cc=changchun.ouyang@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).