All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, marcandre.lureau@redhat.com
Cc: mukawa@igel.co.jp, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 00/14] vhost-user: shutdown and reconnection
Date: Thu, 24 Mar 2016 15:10:01 +0800	[thread overview]
Message-ID: <20160324071001.GA4525@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <20151126121944-mutt-send-email-mst@redhat.com>


On Thu, Nov 26, 2015 at 12:33:22PM +0200, Michael S. Tsirkin wrote:
> On Wed, Sep 09, 2015 at 01:09:52AM +0200, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > 
> > In a previous series "Add feature to start QEMU without vhost-user
> > backend", Tetsuya Mukawa proposed to allow the vhost-user backend to
> > disconnect and reconnect. However, Michael Tsirkin pointed out that
> > you can't do that without extra care, because the guest and hypervisor
> > don't know the slave ring manipulation state, there might be pending
> > replies for example that could be lost, and suggested to reset the
> > guest queues, but this requires kernel changes, and it may have to
> > clear the ring and lose queued packets.

Hi Michael & Marc,

I said I'd would like to have a try last week, and I did. However, I
just be able to have a closer look at the code recently.

> > The following series starts from the idea that the slave can request a
> > "managed" shutdown instead and later recover (I guess the use case for
> > this is to allow for example to update static dispatching/filter rules
> > etc)

What if the backend crashes, that no such request will be sent? And
I'm wondering why this request is needed, as we are able to detect
the disconnect now (with your patches).

BTW, you meant to let QEMU as the server and the backend as the client
here, right? Honestly, that's what we've thought of, too, in the first
time.

However, I'm wondering could we still go with the QEMU as the client
and the backend as the server (the default and the only way DPDK
supports), and let QEMU to try to reconnect when the backend crashes
and restarts. In such case, we need enable the "reconnect" option
for vhost-user, and once I have done that, it basically works in my
test:

- start DPDK vhost-switch example

- start QEMU, which will connect to DPDK vhost-user

  link is good now.

- kill DPDK vhost-switch

  link is broken at this stage

- start DPDK vhost-switch again

  you will find that the link is back again.


Will that makes sense to you? If so, we may need do nothing (or just
very few) changes at all to DPDK to get the reconnect work.

	--yliu

> I'm still not sure users actually need this.  I am inclined to think we
> should teach guests to respond to NEED_RESET status. Then to handle
> disconnect, we would
> - deactivate the disconnected backend
> - stop VM, and wait for a reconnect
> - set NEED_RESET status, and re-activate the backend
>   after guest reset
> 
> -- 
> MST

  parent reply	other threads:[~2016-03-24  7:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 23:09 [Qemu-devel] [PATCH RFC 00/14] vhost-user: shutdown and reconnection marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 01/14] vhost-user: Add ability to know vhost-user backend disconnection marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 02/14] vhost-user: remove useless is_server field marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 03/14] qemu-char: avoid potential double-free marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 04/14] qemu-char: remove all msgfds on disconnect marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 05/14] qemu-char: make tcp_chr_disconnect() reentrant-safe marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 06/14] vhost-net: keep VIRTIO_NET_F_STATUS for vhost-user marcandre.lureau
2015-09-08 23:09 ` [Qemu-devel] [PATCH RFC 07/14] virtio-net: enable tx notification if up and vhost started marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 08/14] vhost: add vhost_dev stop callback marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 09/14] vhost-user: add vhost_user to hold the chr marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 10/14] qemu-char: add qemu_chr_free() marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 11/14] vhost-user: add slave-fd support marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 12/14] vhost-user: add shutdown support marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 13/14] qemu-char: Add qemu_chr_disconnect to close a fd accepted by listen fd marcandre.lureau
2015-09-08 23:10 ` [Qemu-devel] [PATCH RFC 14/14] test: start vhost-user reconnect test marcandre.lureau
2015-11-26 10:33 ` [Qemu-devel] [PATCH RFC 00/14] vhost-user: shutdown and reconnection Michael S. Tsirkin
2016-02-23 18:00   ` Marc-André Lureau
2016-03-02  6:44     ` Michael S. Tsirkin
2016-03-24  7:10   ` Yuanhan Liu [this message]
2016-03-25 18:00     ` Marc-André Lureau
2016-03-28  1:53       ` Tetsuya Mukawa
2016-03-28  2:06         ` Tetsuya Mukawa
2016-03-29  8:10       ` Yuanhan Liu
2016-03-29 10:52         ` Marc-André Lureau
2016-03-29 14:28           ` Yuanhan Liu

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=20160324071001.GA4525@yliu-dev.sh.intel.com \
    --to=yuanhan.liu@linux.intel.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=mukawa@igel.co.jp \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.