From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 010D8A0524;
	Fri, 19 Mar 2021 17:45:50 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 73A88140FF7;
	Fri, 19 Mar 2021 17:45:50 +0100 (CET)
Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230])
 by mails.dpdk.org (Postfix) with ESMTP id D3E7F40143
 for <dev@dpdk.org>; Fri, 19 Mar 2021 17:45:48 +0100 (CET)
Received: from [192.168.1.23] (ip-78-45-89-65.net.upcbroadband.cz
 [78.45.89.65]) (Authenticated sender: i.maximets@ovn.org)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id EF425240009;
 Fri, 19 Mar 2021 16:45:46 +0000 (UTC)
To: Ilya Maximets <i.maximets@ovn.org>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>,
 Chenbo Xia <chenbo.xia@intel.com>, dev@dpdk.org,
 Adrian Moreno <amorenoz@redhat.com>, Julia Suvorova <jusual@redhat.com>
References: <20210317202530.4145673-1-i.maximets@ovn.org>
 <YFS3j3QFsF7X+jlY@stefanha-x1.localdomain>
 <ee5e0d95-1684-c283-c48c-c45cc2bec57b@ovn.org>
From: Ilya Maximets <i.maximets@ovn.org>
Message-ID: <4f26e9a9-8dd1-f619-4337-dcecf35d9f3b@ovn.org>
Date: Fri, 19 Mar 2021 17:45:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <ee5e0d95-1684-c283-c48c-c45cc2bec57b@ovn.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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?

> 
> 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.

> 
> 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.
>