From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f193.google.com (mail-io0-f193.google.com [209.85.223.193]) by dpdk.org (Postfix) with ESMTP id 557241E2F for ; Mon, 9 Jan 2017 10:38:50 +0100 (CET) Received: by mail-io0-f193.google.com with SMTP id 101so2243396iom.0 for ; Mon, 09 Jan 2017 01:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ak7ZEAYO6gyfY4LduzaeSTcVYtw6zU2O81fkK+H7Q6c=; b=hFDzOErjSFIPgS9gaTEmVtMOHoJvK/gA4YCbWQuYEseNmVKzAYYv6h/CQodh7zMUOw gxeZLaGHilguM2btzThGxG2Ep2PPgZ2nChubJL/ojr7N56/LI1Bayrp09opFwZqYLxp4 xwFV14pZZffqVgiDe0TC4hQZPApZjaFliiDnj1eFeWuZMYaDklHlYtJpV/ZoUlhvjhKW uIp9FWARtquVKtpup5/5a9qK7LzXizztjpBbCTS0NWnGZY89pLTX1PzjFbJC+0cT2Xu6 LK5XJlMRjN39jW43pXIGrTl2ewgP5UizPgpDzrQpineKlEd9sibLG2aNRkaoPGbTbZrq /VUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ak7ZEAYO6gyfY4LduzaeSTcVYtw6zU2O81fkK+H7Q6c=; b=iYw3fBW4GzeT2JuUlT6T26p9nuGzS518CJKgMk3VKYrDpRFgDFtLHCkQ/EM62p4oFS Bnr7p1EQD7UgC51xjADhDB4x/qENU/49s03DoYDqi3X654AD8lA8cf72HEwoZ1YdX0ez m3B0ktMoRcYWYQ2gJT5EJFvxilxezfsGna9LlgbSXNvdtSSGE7Dpv4vfuV7alMVhJOCJ XP1BpgGnp51iGWZ+xMUGqBZ0pzOqz3iYYrzCWbE/g5dD6XlkrOHRePUTg1QV0ybxm8sd Eev/m7avtpxZJu291ZMG1046JS4B5MeMOg52+NZJ9BjpU6yDM5i8I0S3rE6jvPuOUpgg vsmQ== X-Gm-Message-State: AIkVDXL5lkFS8jKm9VYl5x9K2rletCogyJ1BXgdOCBjrWd3xTLEHTxJd4OOoLZoZBKLWXJvZ7fyH36kYg6C9nw== X-Received: by 10.107.36.145 with SMTP id k139mr19574201iok.210.1483954729489; Mon, 09 Jan 2017 01:38:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.8.242 with HTTP; Mon, 9 Jan 2017 01:38:48 -0800 (PST) In-Reply-To: <20161222073834.GZ18991@yliu-dev.sh.intel.com> References: <20161222073834.GZ18991@yliu-dev.sh.intel.com> From: Gopakumar Choorakkot Edakkunni Date: Mon, 9 Jan 2017 01:38:48 -0800 Message-ID: To: Yuanhan Liu Cc: huawei.xie@intel.com, dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Bug in virtqueue_dequeue_burst_rx() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 09:38:50 -0000 Hi Yuanahn, Thanks for the response. Because of my filters, I missed this email completely, apologies for the late response ! I haven't tried breaking out of the loop to see if it will go back to working state - I have two testbeds, one using plain linux kvm + guest VM running 16.07 dpdk where I see the problem. I have another testved where I use ovs-dpdk + the same guest VM image running 16.07 dpdk. The issue happens only on the linux kvm setup, so for now I just switched to using ovs-dpdk instead. I will go back sometime to the linux kvm setup and try breaking of the loop and see what happens. Without hardly any knowledge of virtio myself, I am guessing this issue is because the "host" said it has put one buffer into the virtio ring whereas it really did not put the buffer, right ? So is the issue likely to be in the host virtio layer rather than in guest dpdk ? As for the linux-kvm setup, the trigger is very straightforward. Its just sending traffic. The details of my setup are as below. If you have a similar setup, I can possibly try and help you recreate the issue or maybe even provide access to my testbed if you would like that. 1. The guest VM runs dpdk 16.07 and has 8 virtio interfaces mapping to 8 different bridges on the host. The VM has 8Gig memory with 1Gig hugepage size and 1 hugepage (1gig memory) given to dpdk. And the VM is backed up by 16 x 1Gig hugepages on the host. I am attaching the guest XML file here 2. The host runs the below version. And all that I do is send iperf traffic that comes in on one of the 8 interfaces in the guest VM and goes out of another interface in the guest VM. root@ubuntu:/home/vcadmin# uname -a Linux ubuntu 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28 19:17:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux root@ubuntu:/home/vcadmin# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty root@ubuntu:/home/vcadmin# cat /proc/meminfo | grep Huge AnonHugePages: 141312 kB HugePages_Total: 16 HugePages_Free: 16 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 1048576 kB Rgds, Gopa. On Wed, Dec 21, 2016 at 11:38 PM, Yuanhan Liu wrote: > On Mon, Dec 19, 2016 at 09:59:33PM -0800, Gopakumar Choorakkot Edakkunni > wrote: > > While I was testing virtio with ubuntu 14.04 kvm as host and dpdk16.07 > > linux as guest, quite often I have seen that I get into a situation where > > virtio_recv_mergeable_pkts() gets into a forever loop, after sending > > traffic for a while. In the below API, I see that it clearly leads to a > > while loop, I am not quite familiar with virtio or mergeable buffers, so > > thought of checking with dpdk alias on the intent here. > > > > I checked the linux kernel virtio_net.c file which does the similar > > mergeable recieve, and the kernel code breaks out in case of error. > > Shouldnt dpdk be breaking out of here on error instead of continue ? > > Yep, that looks buggy. > > > > > virtio_recv_mergeable_pkts() > > { > > > > while (i < nb_used) { > > > > * num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, 1);* > > * if (num != 1)* > > * continue;* > > However, normally, virtqueue_dequeue_burst_rx() would be successful > here: the outer check (i < nb_used) somehow ascertains it. > > Two options I can think of so far: > > - will it go back working once you do "break" here? > > - tell us how you managed to trigger this issue, so that I could > also reproduce it that I can debug it. > > --yliu >