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 E247C6CB4 for ; Tue, 10 May 2016 09:54:55 +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 5B70349446; Tue, 10 May 2016 07:54:55 +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 u4A7sr5m028496; Tue, 10 May 2016 03:54:54 -0400 Date: Tue, 10 May 2016 10:54:52 +0300 From: "Michael S. Tsirkin" To: "Xie, Huawei" Cc: Yuanhan Liu , "Loftus, Ciara" , "dev@dpdk.org" Message-ID: <20160510105138-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> 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.30]); Tue, 10 May 2016 07:54:55 +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 07:54:56 -0000 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? 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 > > >