From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A182CA0A02; Wed, 24 Mar 2021 21:57:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61072141026; Wed, 24 Mar 2021 21:57:08 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 43784141025 for ; Wed, 24 Mar 2021 21:57:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616619426; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RTqrKK07aP07E7dR4aQEa50eHHAnkXvvjFHlrPRAHzI=; b=bFXVVgW97NnKh7rn7WyB+3NMWcvAto7NkyeJnEzv4JoL/WtpwiC9CMU1kYxLHJpKSaiWCL +Ghc6V/9ZQlMcer2h0O8zYl/95pskCM76DWY5QSrsMx8HoS1PpBzm6VZAAlVaNUsQ8m+UH jf9SNiIReYkXDgUkk5JgboL5iKASzis= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-258-hhIJ-s7mNZ2nmju_Zq42_A-1; Wed, 24 Mar 2021 16:57:02 -0400 X-MC-Unique: hhIJ-s7mNZ2nmju_Zq42_A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F0FC9183CD01; Wed, 24 Mar 2021 20:56:44 +0000 (UTC) Received: from [10.36.110.41] (unknown [10.36.110.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ECF2E19D80; Wed, 24 Mar 2021 20:56:28 +0000 (UTC) To: Ilya Maximets , Stefan Hajnoczi Cc: Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova References: <20210317202530.4145673-1-i.maximets@ovn.org> <4f26e9a9-8dd1-f619-4337-dcecf35d9f3b@ovn.org> From: Maxime Coquelin Message-ID: Date: Wed, 24 Mar 2021 21:56:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <4f26e9a9-8dd1-f619-4337-dcecf35d9f3b@ovn.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Ilya, On 3/19/21 5:45 PM, Ilya Maximets wrote: > On 3/19/21 5:11 PM, Ilya Maximets wrote: >> On 3/19/21 3:39 PM, Stefan Hajnoczi wrote: >>> Hi Ilya, >>> By the way, it's not clear to me why dpdkvhostuser is deprecated. If OVS >>> is restarted then existing vhost-user connections drop with an error but >>> QEMU could attempt to reconnect to the UNIX domain socket which the new >>> OVS instance will set up. >>> >>> Why is it impossible to reconnect when OVS owns the listen socket? >> >> Well, AFAIK, qemu reconnects client connections only: >> >> ``reconnect`` sets the timeout for reconnecting on non-server >> sockets when the remote end goes away. qemu will delay this many >> seconds and then attempt to reconnect. Zero disables reconnecting, >> and is the default. >> >> I'm not sure about exact reason. It was historically this way. >> For me it doesn't make much sense. I mean, your right that it's >> just a socket, so it should not matter who listens and who connects. >> If reconnection is possible in one direction, it should be possible >> in the opposite direction too. > > Sorry, my thought slipped. :) Yes, QEMU supports re-connection > for client sockets. So, in theory, dpdkvhostuser ports should work > after re-connection. And that would be nice. I don't remember > right now why this doesn't work... Maybe vhost-user parts in QEMU > doesn't handle this case. Need to dig some more into that and refresh > my memory. It was so long ago... > > Maxime, do you remember? Sorry for the delay. I didn't remember, so I wanted to have a try. I can confirm reconnect works with QEMU as client and with Vhost PMD as server with:
> >> >> dpdkvhostuser was deprecated just to scare users and force them to >> migrate to dpdkvhostuserclient and avoid constant bug reports like: >> >> "OVS service restarted and network is lost now". >> >> BTW, virtio-user ports in DPDK doesn't support re-connection in client >> mode too. > > This is still true, though. virtio-user in client mode doesn't reconnect. That could be added, and it is maybe not as important for containers as it is for VM to support it, given the ephemeral nature of containers? Regards, Maxime > >> >> BTW2, with SocketPair Broker it might be cheaper to implement server >> reconnection in QEMU because all connections in these case are client >> connections, i.e. both ends will connect() to a broker. >> >> Bets regards, Ilya Maximets. >> >