From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayJY3-0000TZ-CZ for qemu-devel@nongnu.org; Thu, 05 May 2016 09:42:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ayJXr-0007fA-Bf for qemu-devel@nongnu.org; Thu, 05 May 2016 09:42:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayJXr-0007cw-5q for qemu-devel@nongnu.org; Thu, 05 May 2016 09:42:23 -0400 Date: Thu, 5 May 2016 16:42:07 +0300 From: "Michael S. Tsirkin" Message-ID: <20160505163657-mutt-send-email-mst@redhat.com> References: <20160429174835.GH5641@yliu-dev.sh.intel.com> <20160501134233-mutt-send-email-mst@redhat.com> <20160501210442.GK5641@yliu-dev.sh.intel.com> <20160502080610-mutt-send-email-mst@redhat.com> <20160502143051-mutt-send-email-mst@redhat.com> <20160504220549-mutt-send-email-mst@redhat.com> <20160505034437.GX5641@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160505034437.GX5641@yliu-dev.sh.intel.com> Subject: Re: [Qemu-devel] [PATCH 11/18] vhost-user: add shutdown support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yuanhan Liu Cc: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , QEMU , Ilya Maximets , jonshin@cisco.com, Tetsuya Mukawa , "Xie, Huawei" On Wed, May 04, 2016 at 08:44:37PM -0700, Yuanhan Liu wrote: > Hello, > > On Wed, May 04, 2016 at 10:13:49PM +0300, Michael S. Tsirkin wrote: > > How do you avoid it? > > > > > > Management is required to make this robust, auto-reconnect > > > > is handy for people bypassing management. > > > > > > tbh, I don't like autoreconnect. My previous series didn't include > > > this and assumed the feature would be supported only when qemu is > > > configured to be the server. I added reconnect upon request by users. > > > > I don't have better solutions so OK I guess. > > Yes, it's a request from me :) > Well, there may be few others also requested that. > > The reason I had this asking is that, so far, we just have only one > vhost-user frontend, and that is QEMU. But we may have many backends, > I'm aware of 4 at the time writing, including the vubr from QEMU. > While we could do vhost-user client and reconnect implementation > on all backends, it's clear that implementing it in the only backend > (QEMU) introduces more benefits. > > OTOH, I could implement DPDK vhost-user as client and try reconnect > there, if that could makes all stuff a bit easier. > > --yliu In my opinion, if slave initiates disconnecting then slave should also initiate connecting. In a sense, autoretry of connections is not a vhost-user feature. It's a general chardev feature. It also does not have to be related to disconnect: retrying on first connect failure makes exactly as much sense. -- MST