From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id A11B093FE for ; Tue, 10 May 2016 10:42:37 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C39315565; Tue, 10 May 2016 08:42:37 +0000 (UTC) Received: from redhat.com (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id u4A8gZdx026316; Tue, 10 May 2016 04:42:35 -0400 Date: Tue, 10 May 2016 11:42:34 +0300 From: "Michael S. Tsirkin" To: "Xie, Huawei" Cc: Yuanhan Liu , "Loftus, Ciara" , "dev@dpdk.org" Message-ID: <20160510114044-mutt-send-email-mst@redhat.com> References: <1462603224-29510-1-git-send-email-yuanhan.liu@linux.intel.com> <1462603224-29510-4-git-send-email-yuanhan.liu@linux.intel.com> <20160509181254.GE5641@yliu-dev.sh.intel.com> <20160510105138-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 10 May 2016 08:42:37 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 3/6] vhost: add reconnect ability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 08:42:38 -0000 On Tue, May 10, 2016 at 08:07:00AM +0000, Xie, Huawei wrote: > On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote: > > On Tue, May 10, 2016 at 07:24:10AM +0000, Xie, Huawei wrote: > >> On 5/10/2016 2:08 AM, Yuanhan Liu wrote: > >>> On Mon, May 09, 2016 at 04:47:02PM +0000, Xie, Huawei wrote: > >>>> On 5/7/2016 2:36 PM, Yuanhan Liu wrote: > >>>>> +static void * > >>>>> +vhost_user_client_reconnect(void *arg) > >>>>> +{ > >>>>> + struct reconnect_info *reconn = arg; > >>>>> + int ret; > >>>>> + > >>>>> + RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n"); > >>>>> + while (1) { > >>>>> + ret = connect(reconn->fd, (struct sockaddr *)&reconn->un, > >>>>> + sizeof(reconn->un)); > >>>>> + if (ret == 0) > >>>>> + break; > >>>>> + sleep(1); > >>>>> + } > >>>>> + > >>>>> + vhost_user_add_connection(reconn->fd, reconn->vsocket); > >>>>> + free(reconn); > >>>>> + > >>>>> + return NULL; > >>>>> +} > >>>>> + > >>>> We could create hundreds of vhost-user ports in OVS. Wihout connections > >>>> with QEMU established, those ports are just inactive. This works fine in > >>>> server mode. > >>>> With client modes, do we need to create hundreds of vhost threads? This > >>>> would be too interruptible. > >>>> How about we create only one thread and do the reconnections for all the > >>>> unconnected socket? > >>> Yes, good point and good suggestion. Will do it in v2. > >> Hi Michael: > >> This reminds me another irrelevant issue. > >> In OVS, currently for each vhost port, we create an unix domain socket, > >> and QEMU vhost proxy connects to this socket, and we use this to > >> identify the connection. This works fine but is our workaround, > >> otherwise we have no way to identify the connection. > >> Do you think if this is an issue? > > Let us say vhost creates one unix domain socket, with path as "sockpath", > and two virtio ports in two VMS both connect to the same socket with the > following command line > -chardev socket,id=char0,path=sockpath > How could vhost identify the connection? getpeername(2)? > > Workarounds: > vhost creates two unix domain sockets, with path as "sockpath1" and > "sockpath2" respectively, > and the virtio ports in two VMS respectively connect to "sockpath1" and > "sockpath2". > > If we have some name string from QEMU over vhost, as you mentioned, we > could create only one socket with path "sockpath". > User ensure that the names are unique, just as how they do with multiple > sockets. > Seems rather fragile. > > I'm sorry, I have trouble understanding what you wrote above. > > What is the issue you are trying to work around? > > > >> Do we have plan to support identification in VHOST_USER_MESSAGE? With > >> the identification, if vhost as server, we only need to create one > >> socket which receives multiple connections, and use the ID in the > >> message to identify the connection. > >> > >> /huawei > > Sending e.g. -name string from qemu over vhost might be useful > > for debugging, but I'm not sure it's a good idea to > > rely on it being unique. > > > >>> Thanks. > >>> > >>> --yliu > >>> >