DPDK patches and discussions
 help / color / mirror / Atom feed
From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
To: Daniele Di Proietto <diproiettod@vmware.com>
Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>,
	dev <dev@dpdk.org>,
	 "ciara.loftus@intel.com" <ciara.loftus@intel.com>
Subject: Re: [dpdk-dev] Issues with openvswitch2.5+dpdk2.2+kvm/virtio-pci
Date: Wed, 23 Mar 2016 08:19:23 +0100	[thread overview]
Message-ID: <CAATJJ0+DGac2w9Guz2xnUgCn+mCOxshuOSOkpOwSFK2kdOR5Ww@mail.gmail.com> (raw)
In-Reply-To: <D316F5F2.1826D%diproiettod@vmware.com>

On Tue, Mar 22, 2016 at 9:47 PM, Daniele Di Proietto <diproiettod@vmware.com
> wrote:

> Hi Christian,
>
> thanks for the report.  I've managed to reproduce the problem and I
> observed two separate issues:
>
> 1) short version: it appears to be a problem in DPDK 2.2 and it should be
> fixed by 9a0615af7746("virtio: fix restart"), now on master.
>
[...]

> It appears that simply backporting 9a0615af7746("virtio: fix restart")
> fixes the issue.
>

Yeah debugging it I came to the double configuration as cause as well
yesterday.
Eventually I saw that virtqueue->vq_ring structs got reallocated but stayed
zeroed out by the second call.

I didn't realize there was a fix for it already - thanks so much for
pointing it out.
I'll give a backport a try and let you know if it worked.



> 2) When ovs-vswitchd is started with --monitor, there will be a parent
> process (the monitor) that simply restarts the child if it crashes, while
> the child does the actual ovs-vswitchd job.
>
> It appears that the monitor feature is broken with DPDK, because the DPDK
> library is wrongly initialized in the parent process.  If the child
> crashes, all the DPDK memzones are preserved, meaning that new allocations
> will likely fail.
>
> The fix for this is calling rte_eal_init() in the child process, after
> parsing other ovs-vswitchd command line options. This is done (among other
> things) in Aaron's series currently under review:
>
> http://openvswitch.org/pipermail/dev/2016-March/067422.html
>
> I think we need a separate fix for branch-2.5.
>

Yeah I was on discussing and testing that series already as the series was
also related to a socket ownership/permission issue (back in time).
http://openvswitch.org/pipermail/dev/2015-December/063567.html
I think eventually we need separate fixes for both on the branch-2.5

[...]

      reply	other threads:[~2016-03-23  7:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18 15:20 Christian Ehrhardt
2016-03-21  8:16 ` Christian Ehrhardt
2016-03-22 20:47 ` Daniele Di Proietto
2016-03-23  7:19   ` Christian Ehrhardt [this message]

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=CAATJJ0+DGac2w9Guz2xnUgCn+mCOxshuOSOkpOwSFK2kdOR5Ww@mail.gmail.com \
    --to=christian.ehrhardt@canonical.com \
    --cc=ciara.loftus@intel.com \
    --cc=dev@dpdk.org \
    --cc=diproiettod@vmware.com \
    --cc=discuss@openvswitch.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).