From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 10 May 2016 02:00:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,604,1455004800"; d="scan'208";a="972373282" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga002.jf.intel.com with ESMTP; 10 May 2016 02:00:54 -0700 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 May 2016 02:00:49 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx124.amr.corp.intel.com (10.18.125.39) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 May 2016 02:00:48 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.148]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.116]) with mapi id 14.03.0248.002; Tue, 10 May 2016 17:00:46 +0800 From: "Xie, Huawei" To: "Michael S. Tsirkin" CC: Yuanhan Liu , "Loftus, Ciara" , "dev@dpdk.org" Thread-Topic: [PATCH 3/6] vhost: add reconnect ability Thread-Index: AdGqEmkihUidSdHvRW+kJ57Rlmlc4A== 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> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 09:00:56 -0000 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=