From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 08C2D6A15 for ; Tue, 10 May 2016 10:07:03 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 10 May 2016 01:07:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,604,1455004800"; d="scan'208";a="699608037" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 10 May 2016 01:07:04 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 May 2016 01:07:02 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 May 2016 01:07:02 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.148]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0248.002; Tue, 10 May 2016 16:07:01 +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 08:07:00 +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> 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 08:07:04 -0000 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 connection= s=0A= >>>> with QEMU established, those ports are just inactive. This works fine = in=0A= >>>> server mode.=0A= >>>> With client modes, do we need to create hundreds of vhost threads? Thi= s=0A= >>>> would be too interruptible.=0A= >>>> How about we create only one thread and do the reconnections for all t= he=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= =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= =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= =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=