From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xie, Huawei" Subject: Re: [PATCH 3/6] vhost: add reconnect ability Date: Tue, 10 May 2016 09:00:45 +0000 Message-ID: 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> <20160510114044-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Yuanhan Liu , "Loftus, Ciara" , "dev@dpdk.org" To: "Michael S. Tsirkin" Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 87D1A8E6E for ; Tue, 10 May 2016 11:00:55 +0200 (CEST) Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 5/10/2016 4:42 PM, Michael S. Tsirkin wrote:=0A= > On Tue, May 10, 2016 at 08:07:00AM +0000, Xie, Huawei wrote:=0A= >> On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:=0A= >>> On Tue, May 10, 2016 at 07:24:10AM +0000, Xie, Huawei wrote:=0A= >>>> On 5/10/2016 2:08 AM, Yuanhan Liu wrote:=0A= >>>>> On Mon, May 09, 2016 at 04:47:02PM +0000, Xie, Huawei wrote:=0A= >>>>>> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:=0A= >>>>>>> +static void *=0A= >>>>>>> +vhost_user_client_reconnect(void *arg)=0A= >>>>>>> +{=0A= >>>>>>> + struct reconnect_info *reconn =3D arg;=0A= >>>>>>> + int ret;=0A= >>>>>>> +=0A= >>>>>>> + RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");=0A= >>>>>>> + while (1) {=0A= >>>>>>> + ret =3D connect(reconn->fd, (struct sockaddr *)&reconn->un,=0A= >>>>>>> + sizeof(reconn->un));=0A= >>>>>>> + if (ret =3D=3D 0)=0A= >>>>>>> + break;=0A= >>>>>>> + sleep(1);=0A= >>>>>>> + }=0A= >>>>>>> +=0A= >>>>>>> + vhost_user_add_connection(reconn->fd, reconn->vsocket);=0A= >>>>>>> + free(reconn);=0A= >>>>>>> +=0A= >>>>>>> + return NULL;=0A= >>>>>>> +}=0A= >>>>>>> +=0A= >>>>>> We could create hundreds of vhost-user ports in OVS. Wihout connecti= ons=0A= >>>>>> with QEMU established, those ports are just inactive. This works fin= e in=0A= >>>>>> server mode.=0A= >>>>>> With client modes, do we need to create hundreds of vhost threads? T= his=0A= >>>>>> would be too interruptible.=0A= >>>>>> How about we create only one thread and do the reconnections for all= the=0A= >>>>>> unconnected socket?=0A= >>>>> Yes, good point and good suggestion. Will do it in v2.=0A= >>>> Hi Michael:=0A= >>>> This reminds me another irrelevant issue.=0A= >>>> In OVS, currently for each vhost port, we create an unix domain socket= ,=0A= >>>> and QEMU vhost proxy connects to this socket, and we use this to=0A= >>>> identify the connection. This works fine but is our workaround,=0A= >>>> otherwise we have no way to identify the connection.=0A= >>>> Do you think if this is an issue?=0A= >> Let us say vhost creates one unix domain socket, with path as "sockpath"= ,=0A= >> and two virtio ports in two VMS both connect to the same socket with the= =0A= >> following command line=0A= >> -chardev socket,id=3Dchar0,path=3Dsockpath=0A= >> How could vhost identify the connection?=0A= > getpeername(2)?=0A= =0A= getpeer name returns host/port? then it isn't useful.=0A= =0A= The typical scenario in my mind is:=0A= We create a OVS port with the name "port1", and when we receive an=0A= virtio connection with ID "port1", we attach this virtio interface to=0A= the OVS port "port1".=0A= =0A= =0A= >=0A= >=0A= >> Workarounds:=0A= >> vhost creates two unix domain sockets, with path as "sockpath1" and=0A= >> "sockpath2" respectively,=0A= >> and the virtio ports in two VMS respectively connect to "sockpath1" and= =0A= >> "sockpath2".=0A= >>=0A= >> If we have some name string from QEMU over vhost, as you mentioned, we= =0A= >> could create only one socket with path "sockpath".=0A= >> User ensure that the names are unique, just as how they do with multiple= =0A= >> sockets.=0A= >>=0A= > Seems rather fragile.=0A= =0A= >>From the scenario above, it is enough. That is also how it works today=0A= in DPDK OVS implementation with multiple sockets.=0A= Any other idea?=0A= =0A= >=0A= >>> I'm sorry, I have trouble understanding what you wrote above.=0A= >>> What is the issue you are trying to work around?=0A= >>>=0A= >>>> Do we have plan to support identification in VHOST_USER_MESSAGE? With= =0A= >>>> the identification, if vhost as server, we only need to create one=0A= >>>> socket which receives multiple connections, and use the ID in the=0A= >>>> message to identify the connection.=0A= >>>>=0A= >>>> /huawei=0A= >>> Sending e.g. -name string from qemu over vhost might be useful=0A= >>> for debugging, but I'm not sure it's a good idea to=0A= >>> rely on it being unique.=0A= >>>=0A= >>>>> Thanks.=0A= >>>>>=0A= >>>>> --yliu=0A= >>>>>=0A= =0A=